這篇文章為大家?guī)砹岁P(guān)於Redis的相關(guān)知識，其中主要介紹了關(guān)於快取一致性、快取穿透、快取擊穿、快取雪崩以及快取資料的寫同步的與DB一致性的問題，下面一起來看一下，希望對大家有幫助。

相關(guān)推薦：《分析Redis中熱點key儲存問題，聊聊快取異常的解決方法》

（1）快取失效一致性問題

一般快取的使用方式是：先讀取緩存，若不存在則從DB中讀取，並將結(jié)果寫入到快取中；下次資料讀取時便可以直接從快取中取得資料。 【相關(guān)推薦：Redis影片教學(xué)】

資料的修改是直接失效快取數(shù)據(jù)，再修改DB內(nèi)容，避免DB修改成功，但由於網(wǎng)路或其他問題導(dǎo)致快取資料沒有清理，造成了髒數(shù)據(jù)。但這仍然無法避免髒資料的產(chǎn)生，一種並發(fā)的場景下：假設(shè)業(yè)務(wù)對資料Key:Hello Value:World有大量的讀取和修改請求。線程A向OCS讀取Key:Hello，得到Not Found結(jié)果，開始向DB請求數(shù)據(jù)，得到數(shù)據(jù)Key:Hello Value:World；接下來準備向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執(zhí)行緒繼續(xù)執(zhí)行寫入OCS，將Key:Hello Value:World寫入到快取中，A執(zhí)行緒任務(wù)結(jié)束；B執(zhí)行緒也成功修改了DB資料內(nèi)容為Key:Hello Value:OCS。為了解決這個問題，OCS擴充了Memcached協(xié)定（公有雲(yún)即將支援），增加了deleteAndIncVersion介面。此介面並不會真的刪除數(shù)據(jù)，而是給數(shù)據(jù)打了標籤，表示已失效狀態(tài)，並且增加數(shù)據(jù)版本號；如果數(shù)據(jù)不存在則寫入NULL，同時也產(chǎn)生隨機數(shù)據(jù)版本號。 OCS寫入支援原子對比版本號：假設(shè)傳入的版本號與OCS保存的資料版本號一致或原始資料不存在，則準許寫入，否則拒絕修改。

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

此時OCS中的資料為Key:Hello Value:NULL Version:12345；DB中的資料為Key:Hello Value:OCS，後續(xù)讀取任務(wù)時會再次嘗試將DB中的資料寫入到OCS中。

（2）快取資料的寫入同步的與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ù)無法被清除。

從上面的情況可以看出，不一致的根本原因是異質(zhì)系統(tǒng)之間無法協(xié)同同步，無法保證DB資料先同步，快取資料後同步。所以就要考慮快取系統(tǒng)如何等待DB同步，或是能否做到兩者共用一套同步機制？快取同步也依賴DB BINLOG是一個可行的方案。

IDC1中的DB，透過BINLOG同步給IDC2中的DB，此事IDC2-DB資料修改也會產(chǎn)生自身的BINLOG，快取的資料同步就可以透過IDC2-DB BINLOG進行。快取同步模組分析BINLOG後，失效對應(yīng)的快取Key，同步從並行改為串行，確保了先後順序。

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

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

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

（4）快取雪崩（快取設(shè)定同一過期時間，造成的DB洪峰）

#方法一：大多數(shù)系統(tǒng)設(shè)計者考慮用加鎖或佇列的方式保證快取的單執(zhí)行緒（進程）寫，從而避免失效時大量的並發(fā)請求落在底層儲存系統(tǒng)上

方法二：失效時間隨機值

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

? ? 快取在某個時間點過期的時候，恰好在這個時間點對這個Key有大量的並發(fā)請求過來，這些請求發(fā)現(xiàn)快取過期一般都會從後端DB載入資料並回設(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è)定到cache。增加了業(yè)務(wù)程式碼的侵入過多，以及增加了編碼複雜性

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

（6）快取系統(tǒng)常見的快取滿了和資料遺失問題

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

更多程式相關(guān)知識，請造訪：程式設(shè)計影片??！

以上是一起分析Redis快取一致性、快取穿透、快取擊穿及快取雪崩問題的詳細內(nèi)容。更多資訊請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！