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

十余年的鄂溫克網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開(kāi)發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。成都全網(wǎng)營(yíng)銷(xiāo)的優(yōu)勢(shì)是能夠根據(jù)用戶(hù)設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整鄂溫克建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無(wú)論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。成都創(chuàng)新互聯(lián)從事“鄂溫克網(wǎng)站設(shè)計(jì)”,“鄂溫克網(wǎng)站推廣”以來(lái)，每個(gè)客戶(hù)項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。

（1）緩存失效一致性問(wèn)題

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

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

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

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

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

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

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

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

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

（3）緩存穿透（DB承受了沒(méi)有必要的查詢(xún)流量）

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

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

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

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

方法二：失效時(shí)間隨機(jī)值

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

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

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

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

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

（6）緩存系統(tǒng)常見(jiàn)的緩存滿(mǎn)了和數(shù)據(jù)丟失問(wèn)題

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

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