常用于緩存處理的機(jī)制總結(jié) 如何避免緩存雪崩問(wèn)題？

1.緩存和數(shù)據(jù)庫(kù)之間數(shù)據(jù)一致性問(wèn)題

2.緩存穿透問(wèn)題

在實(shí)際的開發(fā)當(dāng)中，我們經(jīng)常需要進(jìn)行磁盤數(shù)據(jù)的讀取和搜索，因此經(jīng)常會(huì)有出現(xiàn)從數(shù)據(jù)庫(kù)讀取數(shù)據(jù)的場(chǎng)景出現(xiàn)。但是當(dāng)數(shù)據(jù)訪問(wèn)量次數(shù)增大的時(shí)候，過(guò)多的磁盤讀取可能會(huì)最終成為整個(gè)系統(tǒng)的性能瓶頸，甚至是壓垮整個(gè)數(shù)據(jù)庫(kù)，導(dǎo)致系統(tǒng)卡死等嚴(yán)重問(wèn)題。

常規(guī)的應(yīng)用系統(tǒng)中，我們通常會(huì)在需要的時(shí)候?qū)?shù)據(jù)庫(kù)進(jìn)行查找，因此系統(tǒng)的大致結(jié)構(gòu)如下所示：

當(dāng)數(shù)據(jù)量較高的時(shí)候，需要減少對(duì)于數(shù)據(jù)庫(kù)里面的磁盤讀寫操作，因此通常都會(huì)選擇在業(yè)務(wù)系統(tǒng)和MySQL數(shù)據(jù)庫(kù)之間加入一層緩存從而減少對(duì)數(shù)據(jù)庫(kù)方面的訪問(wèn)壓力。

但是很多時(shí)候，緩存在實(shí)際項(xiàng)目中的應(yīng)用并非這么簡(jiǎn)單。下邊我們來(lái)通過(guò)幾個(gè)比較經(jīng)典的幾個(gè)緩存應(yīng)用場(chǎng)景來(lái)列舉一些問(wèn)題：

1.緩存和數(shù)據(jù)庫(kù)之間數(shù)據(jù)一致性問(wèn)題

常用于緩存處理的機(jī)制我總結(jié)為了以下幾種：

Cache?Aside,?Read?Through,?Write?Through,?Write?Behind?Caching

首先來(lái)簡(jiǎn)單說(shuō)說(shuō)Cache aside的這種方式：

Cache Aside模式

這種模式處理緩存通常都是先從數(shù)據(jù)庫(kù)緩存查詢，如果緩存沒(méi)有命中則從數(shù)據(jù)庫(kù)中進(jìn)行查找。

這里面會(huì)發(fā)生的三種情況如下：

緩存命中：

當(dāng)查詢的時(shí)候發(fā)現(xiàn)緩存存在，那么直接從緩存中提取。

緩存失效：

當(dāng)緩存沒(méi)有數(shù)據(jù)的時(shí)候，則從database里面讀取源數(shù)據(jù)，再加入到cache里面去。

緩存更新：

當(dāng)有新的寫操作去修改database里面的數(shù)據(jù)時(shí)，需要在寫操作完成之后，讓cache里面對(duì)應(yīng)的數(shù)據(jù)失效。

這種Cache aside模式通常是我們?cè)趯?shí)際應(yīng)用開發(fā)中最為常用到的模式。但是并非說(shuō)這種模式的緩存處理就一定能做到完美，

關(guān)于這種模式下依然會(huì)存在缺陷。比如，一個(gè)是讀操作，但是沒(méi)有命中緩存，然后就到數(shù)據(jù)庫(kù)中取數(shù)據(jù)，此時(shí)來(lái)了一個(gè)寫操作，寫完數(shù)據(jù)庫(kù)后，讓緩存失效，然后，之前的那個(gè)讀操作再把老的數(shù)據(jù)放進(jìn)去，所以，會(huì)造成臟數(shù)據(jù)。

分布式環(huán)境中要想完全的保證數(shù)據(jù)一致性是一件極為困難的事情，我們只能夠盡可能的減低這種數(shù)據(jù)不一致性問(wèn)題產(chǎn)生的情況。

Read Through模式

Read Through模式是指應(yīng)用程序始終從緩存中請(qǐng)求數(shù)據(jù)。如果緩存沒(méi)有數(shù)據(jù)，則它負(fù)責(zé)使用底層提供程序插件從數(shù)據(jù)庫(kù)中檢索數(shù)據(jù)。檢索數(shù)據(jù)后，緩存會(huì)自行更新并將數(shù)據(jù)返回給調(diào)用應(yīng)用程序。使用Read Through 有一個(gè)好處。我們總是使用key從緩存中檢索數(shù)據(jù), 調(diào)用的應(yīng)用程序不知道數(shù)據(jù)庫(kù)， 由存儲(chǔ)方來(lái)負(fù)責(zé)自己的緩存處理，這使代碼更具可讀性， 代碼更清晰。但是這也有相應(yīng)的缺陷，開發(fā)人員需要給編寫相關(guān)的程序插件，增加了開發(fā)的難度性。

Write Through模式

Write Through模式和Read Through模式類似，當(dāng)數(shù)據(jù)發(fā)生更新的時(shí)候，先去Cache里面進(jìn)行更新，如果命中了，則先更新緩存再由Cache方來(lái)更新database。如果沒(méi)有命中的話，就直接更新Database里面的數(shù)據(jù)。

Write Behind Caching模式

Write Behind Caching 這種模式通常是先將數(shù)據(jù)寫入到緩存里面，然后再異步的寫入到database中進(jìn)行數(shù)據(jù)同步，這樣的設(shè)計(jì)既可以直接的減少我們對(duì)于數(shù)據(jù)的database里面的直接訪問(wèn)，降低壓力，同時(shí)對(duì)于database的多次修改可以進(jìn)行合并操作，極大的提升了系統(tǒng)的承載能力。

但是這種模式處理緩存數(shù)據(jù)具有一定的風(fēng)險(xiǎn)性，例如說(shuō)當(dāng)cache機(jī)器出現(xiàn)宕機(jī)的時(shí)候，數(shù)據(jù)會(huì)有丟失的可能。

2.緩存穿透問(wèn)題

在高并發(fā)的場(chǎng)景中，緩存穿透是一個(gè)經(jīng)常都會(huì)遇到的問(wèn)題。

什么是緩存穿透？

大量的請(qǐng)求在緩存中沒(méi)有查詢到指定的數(shù)據(jù)，因此需要從數(shù)據(jù)庫(kù)中進(jìn)行查詢，造成緩存穿透。

會(huì)造成什么后果？

大量的請(qǐng)求短時(shí)間內(nèi)涌入到database中進(jìn)行查詢會(huì)增加database的壓力，最終導(dǎo)致database無(wú)法承載客戶單請(qǐng)求的壓力，出現(xiàn)宕機(jī)卡死等現(xiàn)象。

常用的解決方案通常有以下幾類：

1.空值緩存

在某些特定的業(yè)務(wù)場(chǎng)景中，對(duì)于數(shù)據(jù)的查詢可能會(huì)是空的，沒(méi)有實(shí)際的存在，并且這類數(shù)據(jù)信息在短時(shí)間進(jìn)行多次的反復(fù)查詢也不會(huì)有變化，那么整個(gè)過(guò)程中，多次的請(qǐng)求數(shù)據(jù)庫(kù)操作會(huì)顯得有些多余。不妨可以將這些空值（沒(méi)有查詢結(jié)果的數(shù)據(jù)）對(duì)應(yīng)的key存儲(chǔ)在緩存中，那么第二次查找的時(shí)候就不需要再次請(qǐng)求到database那么麻煩，只需要通過(guò)內(nèi)存查詢即可。這樣的做法能夠大大減少對(duì)于database的訪問(wèn)壓力。

2.布隆過(guò)濾器

通常對(duì)于database里面的數(shù)據(jù)的key值可以預(yù)先存儲(chǔ)在布隆過(guò)濾器里面去，然后先在布隆過(guò)濾器里面進(jìn)行過(guò)濾，如果發(fā)現(xiàn)布隆過(guò)濾器中沒(méi)有的話，就再去redis里面進(jìn)行查詢，如果redis中也沒(méi)有數(shù)據(jù)的話，再去database查詢。這樣可以避免不存在的數(shù)據(jù)信息也去往存儲(chǔ)庫(kù)中進(jìn)行查詢情況。

關(guān)于布隆過(guò)濾器的學(xué)習(xí)可以參考下我的這篇筆記：

https://blog.csdn.net/Danny_idea/article/details/88946673

3.緩存雪崩場(chǎng)景

什么是緩存雪崩？

當(dāng)緩存服務(wù)器重啟或者大量緩存集中在某一個(gè)時(shí)間段失效，這樣在失效的時(shí)候，也會(huì)給后端系統(tǒng)(比如DB)帶來(lái)很大壓力。

如何避免緩存雪崩問(wèn)題？

1.使用加鎖隊(duì)列來(lái)應(yīng)付這種問(wèn)題。 當(dāng)有多個(gè)請(qǐng)求涌入的時(shí)候，當(dāng)緩存失效的時(shí)候加入一把分布式鎖，只允許搶鎖成功的請(qǐng)求去庫(kù)里面讀取數(shù)據(jù)然后將其存入緩存中，再釋放鎖，讓后續(xù)的讀請(qǐng)求從緩存中取數(shù)據(jù)。但是這種做法有一定的弊端，過(guò)多的讀請(qǐng)求線程堵塞，將機(jī)器內(nèi)存占滿，依然沒(méi)有能夠從根本上解決問(wèn)題。

2.在并發(fā)場(chǎng)景發(fā)生前，先手動(dòng)觸發(fā)請(qǐng)求，將緩存都存儲(chǔ)起來(lái) ，以減少后期請(qǐng)求對(duì)database的第一次查詢的壓力。數(shù)據(jù)過(guò)期時(shí)間設(shè)置盡量分散開來(lái)，不要讓數(shù)據(jù)出現(xiàn)同一時(shí)間段出現(xiàn)緩存過(guò)期的情況。

3.從緩存可用性的角度來(lái)思考，避免緩存出現(xiàn)單點(diǎn)故障的問(wèn)題， 可以結(jié)合使用 主從+哨兵的模式來(lái)搭建緩存架構(gòu)，但是這種模式搭建的緩存架構(gòu)有個(gè)弊端，就是無(wú)法進(jìn)行緩存分片，存儲(chǔ)緩存的數(shù)據(jù)量有限制，因此可以升級(jí)為Redis Cluster架構(gòu)來(lái)進(jìn)行優(yōu)化處理。（需要結(jié)合企業(yè)實(shí)際的經(jīng)濟(jì)實(shí)力，畢竟Redis Cluster的搭建需要更多的機(jī)器）

4.Ehcache本地緩存 + Hystrix限流&降級(jí),避免MySQL被打死。

使用 Ehcache本地緩存的目的也是考慮在 Redis Cluster 完全不可用的時(shí)候，Ehcache本地緩存還能夠支撐一陣。

使用 Hystrix進(jìn)行限流 & 降級(jí) ，比如一秒來(lái)了5000個(gè)請(qǐng)求，我們可以設(shè)置假設(shè)只能有一秒 2000個(gè)請(qǐng)求能通過(guò)這個(gè)組件，那么其他剩余的 3000 請(qǐng)求就會(huì)走限流邏輯。

然后去調(diào)用我們自己開發(fā)的降級(jí)組件（降級(jí)），比如設(shè)置的一些默認(rèn)值呀之類的。以此來(lái)保護(hù)最后的 MySQL 不會(huì)被大量的請(qǐng)求給打死。

編輯：黃飛

?