（1）緩存失效一致性問題
一般緩存的使用方式是：先讀取緩存，若不存在則從DB中讀取，并將結(jié)果寫入到緩存中；下次數(shù)據(jù)讀取時(shí)便可以直接從緩存中獲取數(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í)行失效緩存動(dòng)作（因?yàn)锽線程并不知道是否有此條數(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。為了解決這個(gè)問題，OCS擴(kuò)充了Memcached協(xié)議（公有云即將支持），增加了deleteAndIncVersion接口。此接口并不會(huì)真的刪除數(shù)據(jù)，而是給數(shù)據(jù)打了標(biāo)簽，表明已失效狀態(tài)，并且增加數(shù)據(jù)版本號；如果數(shù)據(jù)不存在則寫入NULL，同時(shí)也生成隨機(jī)數(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ù)，版本號信息默認(rèn)為1；在A寫入OCS前另一個(gè)B線程發(fā)起了動(dòng)作修改數(shù)據(jù)Key:Hello Value:OCS，首先執(zhí)行刪除緩存動(dòng)作，OCS順利處理了deleteAndIncVersion請求，生成了隨機(jī)版本號12345（約定大于1000）。轉(zhuǎn)回到A線程繼續(xù)執(zhí)行寫入OCS，請求將Key:Hello Value:World寫入，此時(shí)緩存系統(tǒng)發(fā)現(xiàn)傳入的版本號信息不匹配（1 ！＝ 12345），寫入失敗，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ù)寫入到OCS中。
（2）緩存數(shù)據(jù)的寫同步的與DB一致性問題
隨著網(wǎng)站規(guī)模增長和可靠性的提升，會(huì)面臨多IDC的部署，每個(gè)IDC都有一套獨(dú)立的DB和緩存系統(tǒng)，這時(shí)緩存一致性又成了突出的問題。
首先緩存系統(tǒng)為了保證高效率，會(huì)杜絕磁盤IO，哪怕是寫B(tài)INLOG；當(dāng)然緩存系統(tǒng)為了性能可以只同步刪除，不同步寫入，那么緩存的同步一般會(huì)優(yōu)先于DB同步到達(dá)（畢竟緩存系統(tǒng)的效率要高得多），那么就會(huì)出現(xiàn)緩存中無數(shù)據(jù)，DB中是舊數(shù)據(jù)的場景。此時(shí)，有業(yè)務(wù)請求數(shù)據(jù)，讀取緩存Not Found，從DB讀取并加載到緩存中的仍然是舊數(shù)據(jù)，DB數(shù)據(jù)同步到達(dá)時(shí)也只更新了DB，緩存臟數(shù)據(jù)無法被清除。
從上面的情況可以看出，不一致的根本原因是異構(gòu)系統(tǒng)之間無法協(xié)同同步，不能保證DB數(shù)據(jù)先同步，緩存數(shù)據(jù)后同步。所以就要考慮緩存系統(tǒng)如何等待DB同步，或者能否做到兩者共用一套同步機(jī)制？緩存同步也依賴DB BINLOG是一個(gè)可行的方案。
IDC1中的DB，通過BINLOG同步給IDC2中的DB，此事IDC2-DB數(shù)據(jù)修改也會(huì)產(chǎn)生自身的BINLOG，緩存的數(shù)據(jù)同步就可以通過IDC2-DB BINLOG進(jìn)行。緩存同步模塊分析BINLOG后，失效相應(yīng)的緩存Key，同步從并行改為串行，保證了先后順序。
（3）緩存穿透（DB承受了沒有必要的查詢流量）
方法一：是布隆過濾器。它是一種空間效率極高的概率型算法和數(shù)據(jù)結(jié)構(gòu)，用于判斷一個(gè)元素是否在集合中(類似Hashset)。它的核心是一個(gè)很長的二進(jìn)制向量和一系列的hash函數(shù)。使用谷歌的guava實(shí)現(xiàn)布隆過濾器。1）存在誤算率，隨著存入的元素?cái)?shù)量增加，誤算率也隨著增加2)一般情況下不能從布隆過濾器刪除元素3)數(shù)組長度以及hash函數(shù)個(gè)數(shù)確定過程復(fù)雜，布隆過濾器的使用場景？1)垃圾郵件地址過濾(地址數(shù)量很龐大)2)爬蟲URL地址去重3)解決緩存擊穿問題
方法二：存儲(chǔ)空結(jié)果，并設(shè)置空結(jié)果的時(shí)間
（4）緩存雪崩（緩存設(shè)置同一過期時(shí)間，引起的DB洪峰）
方法一：大多數(shù)系統(tǒng)設(shè)計(jì)者考慮用加鎖或者隊(duì)列的方式保證緩存的單線 程（進(jìn)程）寫，從而避免失效時(shí)大量的并發(fā)請求落到底層存儲(chǔ)系統(tǒng)上
方法二：失效時(shí)間隨機(jī)值
（5）緩存擊穿（熱點(diǎn)Key，大量并發(fā)讀請求引起的小雪崩）
緩存在某個(gè)時(shí)間點(diǎn)過期的時(shí)候，恰好在這個(gè)時(shí)間點(diǎn)對這個(gè)Key有大量的并發(fā)請求過來，這些請求發(fā)現(xiàn)緩存過期一般都會(huì)從后端DB加載數(shù)據(jù)并回設(shè)到緩存，這個(gè)時(shí)候大并發(fā)的請求可能會(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)過期時(shí)候，馬上延長timeout1并重新設(shè)置到cache。然后再從數(shù)據(jù)庫加載數(shù)據(jù)并設(shè)置到cache中。增加了業(yè)務(wù)代碼的侵入過多，以及增加了編碼復(fù)雜性
方法三： "永遠(yuǎn)不過期"： 從redis上看，確實(shí)沒有設(shè)置過期時(shí)間，這就保證了，不會(huì)出現(xiàn)熱點(diǎn)key過期問題，也就是“物理”不過期。從功能上看，如果不過期，那不就成靜態(tài)的了嗎？所以我們把過期時(shí)間存在key對應(yīng)的value里，如果發(fā)現(xiàn)要過期了，通過一個(gè)后臺(tái)的異步線程進(jìn)行緩存的構(gòu)建，也就是“邏輯”過期
（6）緩存系統(tǒng)常見的緩存滿了和數(shù)據(jù)丟失問題
需要根據(jù)具體業(yè)務(wù)分析，通常我們采用LRU策略處理溢出，Redis的RDB和AOF持久化策略來保證一定情況下的數(shù)據(jù)安全。
本文參考：
