Redis緩存一致性、緩存穿透、緩存擊穿及緩存雪崩問題分析

本篇內(nèi)容介紹了“Redis緩存一致性、緩存穿透、緩存擊穿及緩存雪崩問題分析”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

（1）緩存失效一致性問題

一般緩存的使用方式是：先讀取緩存，若不存在則從DB中讀取，并將結(jié)果寫入到緩存中；下次數(shù)據(jù)讀取時便可以直接從緩存中獲取數(shù)據(jù)。

數(shù)據(jù)的修改是直接失效緩存數(shù)據(jù)，再修改DB內(nèi)容，避免DB修改成功，但由于網(wǎng)絡(luò)或者其他問題導(dǎo)致緩存數(shù)據(jù)沒有清理，造成了臟數(shù)據(jù)。但這樣仍然無法避免臟數(shù)據(jù)的產(chǎn)生，一種并發(fā)的場景下：假設(shè)業(yè)務(wù)對數(shù)據(jù)Key:Hello Value:World有大量的讀取和修改請求。線程A向OCS讀取Key:Hello，得到Not Found結(jié)果，開始向DB請求數(shù)據(jù)，得到數(shù)據(jù)Key:Hello Value:World；接下來準(zhǔn)備向OCS寫入此條數(shù)據(jù)，但在寫入OCS前（網(wǎng)絡(luò)，CPU都等可能導(dǎo)致A線程處理速度降低）另一B線程請求修改數(shù)據(jù)Key:Hello Value:OCS，首先執(zhí)行失效緩存動作（因為B線程并不知道是否有此條數(shù)據(jù)，因此直接執(zhí)行失效操作），OCS成功處理了失效請求。轉(zhuǎn)回到A線程繼續(xù)執(zhí)行寫入OCS，將Key:Hello Value:World寫入到緩存中，A線程任務(wù)結(jié)束；B線程也成功修改了DB數(shù)據(jù)內(nèi)容為Key:Hello Value:OCS。為了解決這個問題，OCS擴充了Memcached協(xié)議（公有云即將支持），增加了deleteAndIncVersion接口。此接口并不會真的刪除數(shù)據(jù)，而是給數(shù)據(jù)打了標(biāo)簽，表明已失效狀態(tài)，并且增加數(shù)據(jù)版本號；如果數(shù)據(jù)不存在則寫入NULL，同時也生成隨機數(shù)據(jù)版本號。OCS寫入支持原子對比版本號：假設(shè)傳入的版本號與OCS保存的數(shù)據(jù)版本號一致或者原數(shù)據(jù)不存在，則準(zhǔn)許寫入，否則拒絕修改。

回到剛才的場景上：線程A向OCS讀取Key:Hello，得到Not Found結(jié)果，開始向DB請求數(shù)據(jù)，得到數(shù)據(jù)Key:Hello Value:World；接下來準(zhǔn)備向OCS寫入此條數(shù)據(jù)，版本號信息默認為1；在A寫入OCS前另一個B線程發(fā)起了動作修改數(shù)據(jù)Key:Hello Value:OCS，首先執(zhí)行刪除緩存動作，OCS順利處理了deleteAndIncVersion請求，生成了隨機版本號12345（約定大于1000）。轉(zhuǎn)回到A線程繼續(xù)執(zhí)行寫入OCS，請求將Key:Hello Value:World寫入，此時緩存系統(tǒng)發(fā)現(xiàn)傳入的版本號信息不匹配（1 ?。?12345），寫入失敗，A線程任務(wù)結(jié)束；B線程也成功修改了DB數(shù)據(jù)內(nèi)容為Key:Hello Value:OCS。

此時OCS中的數(shù)據(jù)為Key:Hello Value:NULL Version:12345；DB中的數(shù)據(jù)為Key:Hello Value:OCS，后續(xù)讀任務(wù)時會再次嘗試將DB中的數(shù)據(jù)寫入到OCS中。

（2）緩存數(shù)據(jù)的寫同步的與DB一致性問題

隨著網(wǎng)站規(guī)模增長和可靠性的提升，會面臨多IDC的部署，每個IDC都有一套獨立的DB和緩存系統(tǒng)，這時緩存一致性又成了突出的問題。

首先緩存系統(tǒng)為了保證高效率，會杜絕磁盤IO，哪怕是寫B(tài)INLOG；當(dāng)然緩存系統(tǒng)為了性能可以只同步刪除，不同步寫入，那么緩存的同步一般會優(yōu)先于DB同步到達（畢竟緩存系統(tǒng)的效率要高得多），那么就會出現(xiàn)緩存中無數(shù)據(jù)，DB中是舊數(shù)據(jù)的場景。此時，有業(yè)務(wù)請求數(shù)據(jù)，讀取緩存Not Found，從DB讀取并加載到緩存中的仍然是舊數(shù)據(jù)，DB數(shù)據(jù)同步到達時也只更新了DB，緩存臟數(shù)據(jù)無法被清除。

從上面的情況可以看出，不一致的根本原因是異構(gòu)系統(tǒng)之間無法協(xié)同同步，不能保證DB數(shù)據(jù)先同步，緩存數(shù)據(jù)后同步。所以就要考慮緩存系統(tǒng)如何等待DB同步，或者能否做到兩者共用一套同步機制？緩存同步也依賴DB BINLOG是一個可行的方案。

IDC1中的DB，通過BINLOG同步給IDC2中的DB，此事IDC2-DB數(shù)據(jù)修改也會產(chǎn)生自身的BINLOG，緩存的數(shù)據(jù)同步就可以通過IDC2-DB BINLOG進行。緩存同步模塊分析BINLOG后，失效相應(yīng)的緩存Key，同步從并行改為串行，保證了先后順序。

（3）緩存穿透（DB承受了沒有必要的查詢流量）

方法一：是布隆過濾器。它是一種空間效率極高的概率型算法和數(shù)據(jù)結(jié)構(gòu)，用于判斷一個元素是否在集合中(類似Hashset)。它的核心是一個很長的二進制向量和一系列的hash函數(shù)。使用谷歌的guava實現(xiàn)布隆過濾器。1）存在誤算率，隨著存入的元素數(shù)量增加，誤算率也隨著增加2)一般情況下不能從布隆過濾器刪除元素3)數(shù)組長度以及hash函數(shù)個數(shù)確定過程復(fù)雜，布隆過濾器的使用場景？1)垃圾郵件地址過濾(地址數(shù)量很龐大)2)爬蟲URL地址去重3)解決緩存擊穿問題

方法二：存儲空結(jié)果，并設(shè)置空結(jié)果的時間

（4）緩存雪崩（緩存設(shè)置同一過期時間，引起的DB洪峰）

方法一：大多數(shù)系統(tǒng)設(shè)計者考慮用加鎖或者隊列的方式保證緩存的單線 程（進程）寫，從而避免失效時大量的并發(fā)請求落到底層存儲系統(tǒng)上

方法二：失效時間隨機值

（5）緩存擊穿（熱點Key，大量并發(fā)讀請求引起的小雪崩）

緩存在某個時間點過期的時候，恰好在這個時間點對這個Key有大量的并發(fā)請求過來，這些請求發(fā)現(xiàn)緩存過期一般都會從后端DB加載數(shù)據(jù)并回設(shè)到緩存，這個時候大并發(fā)的請求可能會瞬間把后端DB壓垮

方法一：1.使用分布是緩存支持的互斥鎖(mutex key)，去set一個mutex key，當(dāng)操作返回成功時，再進行l(wèi)oad db的操作并回設(shè)緩存，也就是load DB 只會一個線程處理。

方法二：提前"使用互斥鎖(mutex key)：在value內(nèi)部設(shè)置1個超時值(timeout1), timeout1比實際的memcache timeout(timeout2)小。當(dāng)從cache讀取到timeout1發(fā)現(xiàn)它已經(jīng)過期時候，馬上延長timeout1并重新設(shè)置到cache。然后再從數(shù)據(jù)庫加載數(shù)據(jù)并設(shè)置到cache中。增加了業(yè)務(wù)代碼的侵入過多，以及增加了編碼復(fù)雜性

方法三： "永遠不過期"： 從redis上看，確實沒有設(shè)置過期時間，這就保證了，不會出現(xiàn)熱點key過期問題，也就是“物理”不過期。從功能上看，如果不過期，那不就成靜態(tài)的了嗎？所以我們把過期時間存在key對應(yīng)的value里，如果發(fā)現(xiàn)要過期了，通過一個后臺的異步線程進行緩存的構(gòu)建，也就是“邏輯”過期

（6）緩存系統(tǒng)常見的緩存滿了和數(shù)據(jù)丟失問題

需要根據(jù)具體業(yè)務(wù)分析，通常我們采用LRU策略處理溢出，Redis的RDB和AOF持久化策略來保證一定情況下的數(shù)據(jù)安全。

“Redis緩存一致性、緩存穿透、緩存擊穿及緩存雪崩問題分析”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！