本文圍繞以下幾點(diǎn)進(jìn)行闡述：
- 為什么使用redis
- 使用Redis有什么缺點(diǎn)
- 單線程的Redis為什么這么快
- Redis的數(shù)據(jù)類型，以及每種數(shù)據(jù)類型的使用場景
- Redis的過期策略以及內(nèi)存淘汰機(jī)制
- Redis和數(shù)據(jù)庫雙寫一致性問題
- 如何應(yīng)對緩存穿透和緩存雪崩問題
- 如何解決Redis的并發(fā)競爭問題
一、為什么使用Redis
筆者認(rèn)為，在項(xiàng)目中使用Redis，主要是從兩個(gè)角度去考慮：性能和并發(fā)。當(dāng)然，Redis還具備可做分布式鎖等功能的其它功能，但如果只是為了分布式鎖這些其它功能，完全還有其它中間件（如Zookpeer等）可以代替，并不是非要使用Redis。
因此，這個(gè)問題主要從性能和并發(fā)兩個(gè)角度去答：
1、性能
如下圖所示，我們在碰到需要執(zhí)行耗時(shí)特別久、且結(jié)果不頻繁變動(dòng)的SQL時(shí)，就特別適合將運(yùn)行結(jié)果放入緩存。這樣，后面的請求就去緩存中讀取，使得請求能夠迅速響應(yīng)。
題外話：忽然想聊一下這個(gè)迅速響應(yīng)的標(biāo)準(zhǔn)——其實(shí)根據(jù)交互效果的不同，這個(gè)響應(yīng)時(shí)間沒有固定標(biāo)準(zhǔn)。不過曾經(jīng)有人這么告訴我：“在理想狀態(tài)下，我們的頁面跳轉(zhuǎn)需要在瞬間解決，對于頁內(nèi)操作則需要在剎那間解決。另外，超過一彈指的耗時(shí)操作要有進(jìn)度提示，并且可以隨時(shí)中止或取消，這樣才能給用戶最好的體驗(yàn)。”
那么瞬間、剎那、一彈指具體是多少時(shí)間呢？
根據(jù)《摩訶僧祗律》記載：一剎那者為一念，二十念為一瞬，二十瞬為一彈指，二十彈指為一羅預(yù)，二十羅預(yù)為一須臾，一日一夜有三十須臾。
那么，經(jīng)過周密的計(jì)算，一瞬間為0.36秒,一剎那有0.018秒，一彈指長達(dá)7.2秒。
2、并發(fā)
如下圖所示，在大并發(fā)的情況下，所有的請求直接訪問數(shù)據(jù)庫，數(shù)據(jù)庫會(huì)出現(xiàn)連接異常。這個(gè)時(shí)候，就需要使用Redis做一個(gè)緩沖操作，讓請求先訪問到Redis，而不是直接訪問數(shù)據(jù)庫。
二、使用Redis有什么缺點(diǎn)
大家用Redis這么久，這個(gè)問題是必須要了解的，基本上使用Redis都會(huì)碰到一些問題，常見的主要是四方面的問題：
- 緩存和數(shù)據(jù)庫雙寫一致性問題
- 緩存雪崩問題
- 緩存擊穿問題
- 緩存的并發(fā)競爭問題
這四個(gè)問題，筆者個(gè)人覺得在項(xiàng)目中比較常遇見，具體解決方案，后文會(huì)給出。
三、單線程的Redis為什么這么快
這個(gè)問題其實(shí)是對Redis內(nèi)部機(jī)制的一個(gè)考察。其實(shí)根據(jù)筆者的面試經(jīng)驗(yàn)，很多人其實(shí)都不知道Redis是單線程工作模型。所以，這個(gè)問題還是應(yīng)該要復(fù)習(xí)一下的。主要是以下三點(diǎn)：
- 純內(nèi)存操作
- 單線程操作，避免了頻繁的上下文切換
- 采用了非阻塞I/O多路復(fù)用機(jī)制
我們現(xiàn)在仔細(xì)地說一說I/O多路復(fù)用機(jī)制，因?yàn)檫@個(gè)說法實(shí)在是太通俗了，通俗到一般人都不懂是什么意思。打一個(gè)比方：小曲在S城開了一家快遞店，負(fù)責(zé)同城快送服務(wù)。小曲因?yàn)橘Y金限制，雇傭了一批快遞員，然后小曲發(fā)現(xiàn)資金不夠了，只夠買一輛車送快遞。
經(jīng)營方式一：
客戶每送來一份快遞，小曲就讓一個(gè)快遞員盯著，然后快遞員開車去送快遞。慢慢的小曲就發(fā)現(xiàn)了這種經(jīng)營方式存在很多問題，幾十個(gè)快遞員基本上時(shí)間都花在了搶車上了，大部分快遞員都處在閑置狀態(tài)，誰搶到了車，誰就能去送快遞。
隨著快遞的增多，快遞員也越來越多，小曲發(fā)現(xiàn)快遞店里越來越擠，沒辦法雇傭新的快遞員了，快遞員之間的協(xié)調(diào)很花時(shí)間，大部分時(shí)間花在搶車上。綜合上述缺點(diǎn)，小曲痛定思痛，提出了下面的經(jīng)營方式↓
經(jīng)營方式二：
小曲只雇傭一個(gè)快遞員，客戶送來的快遞，小曲按送達(dá)地點(diǎn)標(biāo)注好，然后依次放在一個(gè)地方。最后，那個(gè)快遞員依次去取快遞，一次拿一個(gè)，開著車去送快遞，送好了就回來拿下一個(gè)快遞。
上述兩種經(jīng)營方式對比，是不是明顯覺得第二種，效率更高、更好呢？在上述比喻中：
- 每個(gè)快遞員→每個(gè)線程
- 每個(gè)快遞→每個(gè)Socket(I/O流)
- 快遞的送達(dá)地點(diǎn)→Socket的不同狀態(tài)
- 客戶送快遞請求→來自客戶端的請求
- 小曲的經(jīng)營方式→服務(wù)端運(yùn)行的代碼
- 一輛車→CPU的核數(shù)
于是我們有如下結(jié)論：
- 經(jīng)營方式一就是傳統(tǒng)的并發(fā)模型，每個(gè)I/O流(快遞)都有一個(gè)新的線程(快遞員)管理。
- 經(jīng)營方式二就是I/O多路復(fù)用。只有單個(gè)線程(一個(gè)快遞員)，通過跟蹤每個(gè)I/O流的狀態(tài)(每個(gè)快遞的送達(dá)地點(diǎn))，來管理多個(gè)I/O流。
下面類比到真實(shí)的Redis線程模型，如圖所示：
參照上圖，簡單來說就是，我們的Redis-client在操作的時(shí)候，會(huì)產(chǎn)生具有不同事件類型的Socket。在服務(wù)端，有一段I/O多路復(fù)用程序，將其置入隊(duì)列之中。然后文件事件分派器依次去隊(duì)列中取，轉(zhuǎn)發(fā)到不同的事件處理器中。
需要說明的是，這個(gè)I/O多路復(fù)用機(jī)制，Redis還提供了Select、Epoll、Evport、Kqueue等多路復(fù)用函數(shù)庫，大家可以自行去了解。
四、Redis的數(shù)據(jù)類型及各自使用場景
看到這個(gè)問題，是不是覺得它很基礎(chǔ)？其實(shí)筆者也這么覺得。然而根據(jù)面試經(jīng)驗(yàn)發(fā)現(xiàn)，至少80%的人答不上這個(gè)問題。建議在項(xiàng)目中用到后，再類比記憶，體會(huì)更深，不要硬記?；旧?，一個(gè)合格的程序員五種類型都會(huì)用到：
1、String
這個(gè)其實(shí)沒什么好說的，最常規(guī)的Set/Get操作，Value可以是String也可以是數(shù)字，一般做一些復(fù)雜的計(jì)數(shù)功能的緩存。
2、Hash
這里Value存放的是結(jié)構(gòu)化的對象，比較方便的就是操作其中的某個(gè)字段。筆者在做單點(diǎn)登錄的時(shí)候，就是用這種數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)用戶信息，以CookieId作為Key，設(shè)置30分鐘為緩存過期時(shí)間，能很好地模擬出類似Session的效果。
3、List
使用List的數(shù)據(jù)結(jié)構(gòu)，可以做簡單的消息隊(duì)列的功能。另外還有一個(gè)就是，可以利用Lrange命令，做基于Redis的分頁功能，性能極佳，用戶體驗(yàn)好。
4、Set
因?yàn)镾et堆放的是一堆不重復(fù)值的集合，所以可以做全局去重的功能。
為什么不用JVM自帶的Set進(jìn)行去重？因?yàn)槲覀兊南到y(tǒng)一般都是集群部署，使用JVM自帶的Set比較麻煩，難道為了做一個(gè)全局去重，再起一個(gè)公共服務(wù)？太麻煩了。
另外，就是利用交集、并集、差集等操作，可以計(jì)算共同喜好、全部的喜好、自己獨(dú)有的喜好等功能。
5、Sorted Set
Sorted Set多了一個(gè)權(quán)重參數(shù)Score，集合中的元素能夠按Score進(jìn)行排列?？梢宰雠判邪駪?yīng)用，取TOP N操作。另外，Sorted Set還可以用來做延時(shí)任務(wù)。最后一個(gè)應(yīng)用就是可以做范圍查找。
五、Redis的過期策略及內(nèi)存淘汰機(jī)制
這個(gè)問題其實(shí)相當(dāng)重要，從這個(gè)問題就可以看出來到底R(shí)edis有沒有用到位。比如，你Redis只能存5G數(shù)據(jù)，可是你寫了10G，那會(huì)刪5G的數(shù)據(jù)。怎么刪的？這個(gè)問題思考過么？還有，你的數(shù)據(jù)已經(jīng)設(shè)置了過期時(shí)間，但是時(shí)間到了，內(nèi)存占用率還是比較高，有思考過原因么?
Redis采用的是定期刪除+惰性刪除策略。
為什么不用定時(shí)刪除策略？
定時(shí)刪除，用一個(gè)定時(shí)器來負(fù)責(zé)監(jiān)視Key，過期則自動(dòng)刪除。雖然內(nèi)存及時(shí)釋放，但是十分消耗CPU資源。在大并發(fā)請求下，CPU要將時(shí)間應(yīng)用在處理請求，而不是刪除Key，因此沒有采用這一策略。
定期刪除+惰性刪除是如何工作的呢？
定期刪除，Redis默認(rèn)每個(gè)100ms檢查是否有過期的Key，有過期Key則刪除。需要說明的是，Redis不是每個(gè)100ms將所有的Key檢查一次，而是隨機(jī)抽取進(jìn)行檢查（如果每隔100ms，全部Key進(jìn)行檢查，Redis豈不是卡死）。因此，如果只采用定期刪除策略，會(huì)導(dǎo)致很多Key到時(shí)間沒有刪除。
于是，惰性刪除派上用場。也就是說在你獲取某個(gè)Key的時(shí)候，Redis會(huì)檢查一下，這個(gè)Key如果設(shè)置了過期時(shí)間，那么是否過期了？如果過期了此時(shí)就會(huì)刪除。
采用定期刪除+惰性刪除就沒其他問題了么？
不是的，如果定期刪除沒刪除Key。然后你也沒及時(shí)去請求Key，也就是說惰性刪除也沒生效。這樣，Redis的內(nèi)存會(huì)越來越高，那么就應(yīng)該采用內(nèi)存淘汰機(jī)制。
在Redis.conf中有一行配置：
# maxmemory-policy volatile-lru
該配置就是配內(nèi)存淘汰策略的：
- Noeviction：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，新寫入操作會(huì)報(bào)錯(cuò)。應(yīng)該沒人使用吧；
- Allkeys-lru：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，在鍵空間中，移除最近最少使用的Key。推薦使用，目前項(xiàng)目在用這種；
- Allkeys-random：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，在鍵空間中，隨機(jī)移除某個(gè)key，應(yīng)該也沒人使用吧；
- Volatile-lru：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，在設(shè)置了過期時(shí)間的鍵空間中，移除最近最少使用的Key。這種情況一般是把Redis既當(dāng)緩存又做持久化存儲(chǔ)的時(shí)候才用。不推薦；
- Volatile-random：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，在設(shè)置了過期時(shí)間的鍵空間中，隨機(jī)移除某個(gè)Key。依然不推薦；
- Volatile-ttl：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，在設(shè)置了過期時(shí)間的鍵空間中，有更早過期時(shí)間的Key優(yōu)先移除。不推薦。
PS：如果沒有設(shè)置Expire的Key，不滿足先決條件（Prerequisites）；那么Volatile-lru、Volatile-random和Volatile-ttl策略的行為，和Noeviction（不刪除）基本上一致。
六、Redis和數(shù)據(jù)庫雙寫一致性問題
一致性問題是分布式常見問題，還可以再分為最終一致性和強(qiáng)一致性。數(shù)據(jù)庫和緩存雙寫，就必然會(huì)存在不一致的問題，想要回答這個(gè)問題，就要先明白一個(gè)前提：如果對數(shù)據(jù)有強(qiáng)一致性要求，就不能放緩存。我們所做的一切，只能保證最終一致性。
另外，我們所做的方案其實(shí)從根本上來說，只能說降低不一致發(fā)生的概率，無法完全避免。因此，有強(qiáng)一致性要求的數(shù)據(jù)不能放緩存。
在互聯(lián)網(wǎng)領(lǐng)域，緩存由于其高并發(fā)和高性能的特性，已經(jīng)在項(xiàng)目中被廣泛使用。在讀取緩存方面，大家沒什么疑問，都是按照下圖的流程來進(jìn)行業(yè)務(wù)操作。
但是在更新緩存方面，對于更新完數(shù)據(jù)庫，是更新緩存呢，還是刪除緩存；又或者是先刪除緩存，再更新數(shù)據(jù)庫，其實(shí)大家存在很大的爭議。
從理論上來說，給緩存設(shè)置過期時(shí)間，是保證最終一致性的解決方案。這種方案下，我們可以對存入緩存的數(shù)據(jù)設(shè)置過期時(shí)間，所有的寫操作以數(shù)據(jù)庫為準(zhǔn)，對緩存操作只是盡最大努力即可。也就是說如果數(shù)據(jù)庫寫成功，緩存更新失敗，那么只要到達(dá)過期時(shí)間，則后面的讀請求自然會(huì)從數(shù)據(jù)庫中讀取新值然后回填緩存。因此，接下來討論的思路不依賴于給緩存設(shè)置過期時(shí)間這個(gè)方案。
在這里，我們討論三種更新策略：
- 先更新數(shù)據(jù)庫，再更新緩存；
- 先刪除緩存，再更新數(shù)據(jù)庫；
- 先更新數(shù)據(jù)庫，再刪除緩存。
應(yīng)該沒有人會(huì)問我，為什么沒有先更新緩存，再更新數(shù)據(jù)庫這種策略吧？
1、先更新數(shù)據(jù)庫，再更新緩存
這套方案，大家是普遍反對的。為什么呢？有如下兩點(diǎn)原因。
- 原因一（線程安全角度）
同時(shí)有請求A和請求B進(jìn)行更新操作，那么會(huì)出現(xiàn)
- 線程A更新了數(shù)據(jù)庫；
- 線程B更新了數(shù)據(jù)庫；
- 線程B更新了緩存；
- 線程A更新了緩存。
這就出現(xiàn)請求A更新緩存應(yīng)該比請求B更新緩存早才對，但是因?yàn)榫W(wǎng)絡(luò)等原因，B卻比A更早更新了緩存。這就導(dǎo)致了臟數(shù)據(jù)，因此不考慮。
- 原因二（業(yè)務(wù)場景角度）
有如下兩點(diǎn)：
- 如果你是一個(gè)寫數(shù)據(jù)庫場景比較多，而讀數(shù)據(jù)場景比較少的業(yè)務(wù)需求，采用這種方案就會(huì)導(dǎo)致，數(shù)據(jù)壓根還沒讀到，緩存就被頻繁地更新，浪費(fèi)性能；
- 如果你寫入數(shù)據(jù)庫的值，并不是直接寫入緩存的，而是要經(jīng)過一系列復(fù)雜的計(jì)算再寫入緩存。那么，每次寫入數(shù)據(jù)庫后，都再次計(jì)算寫入緩存的值，無疑是浪費(fèi)性能的。顯然，刪除緩存更為適合。
接下來討論的就是爭議最大的，是先刪緩存、再更新數(shù)據(jù)庫，還是先更新數(shù)據(jù)庫、再刪緩存的問題。
二、先刪除緩存，再更新數(shù)據(jù)庫
該方案會(huì)導(dǎo)致不一致的原因是，同時(shí)有一個(gè)請求A進(jìn)行更新操作，另一個(gè)請求B進(jìn)行查詢操作。那么會(huì)出現(xiàn)如下情形：
- 請求A進(jìn)行寫操作，刪除緩存；
- 請求B查詢發(fā)現(xiàn)緩存不存在；
- 請求B去數(shù)據(jù)庫查詢得到舊值；
- 請求B將舊值寫入緩存；
- 請求A將新值寫入數(shù)據(jù)庫。
上述情況就會(huì)導(dǎo)致不一致的情形出現(xiàn)。而且，如果不采用給緩存設(shè)置過期時(shí)間策略，該數(shù)據(jù)永遠(yuǎn)都是臟數(shù)據(jù)。
那么，如何解決呢？采用延時(shí)雙刪策略。
偽代碼如下：
public void write(String key,Object data){
redis.delKey(key);
db.updateData(data);
Thread.sleep(1000);
redis.delKey(key);
}
轉(zhuǎn)化為中文描述就是：
- 先淘汰緩存；
- 再寫數(shù)據(jù)庫（這兩步和原來一樣）；
- 休眠1秒，再次淘汰緩存。
這么做，可以將1秒內(nèi)所造成的緩存臟數(shù)據(jù)，再次刪除。
那么，這個(gè)1秒是怎么確定的，具體該休眠多久呢？
針對上面的情形，讀者應(yīng)該自行評(píng)估自己的項(xiàng)目的讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時(shí)。然后寫數(shù)據(jù)的休眠時(shí)間則在讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時(shí)基礎(chǔ)上，加幾百ms即可。這么做的目的，就是確保讀請求結(jié)束，寫請求可以刪除讀請求造成的緩存臟數(shù)據(jù)。
如果你用了MySQL的讀寫分離架構(gòu)怎么辦？
在這種情況下，造成數(shù)據(jù)不一致的原因如下，還是兩個(gè)請求，一個(gè)請求A進(jìn)行更新操作，另一個(gè)請求B進(jìn)行查詢操作。
- 請求A進(jìn)行寫操作，刪除緩存；
- 請求A將數(shù)據(jù)寫入數(shù)據(jù)庫了；
- 請求B查詢緩存發(fā)現(xiàn)，緩存沒有值；
- 請求B去從庫查詢，這時(shí)，還沒有完成主從同步，因此查詢到的是舊值；
- 請求B將舊值寫入緩存；
- 數(shù)據(jù)庫完成主從同步，從庫變?yōu)樾轮怠?/li>
上述情形，就是數(shù)據(jù)不一致的原因。還是使用雙刪延時(shí)策略。只是，睡眠時(shí)間修改為在主從同步的延時(shí)時(shí)間基礎(chǔ)上，加幾百ms。
采用這種同步淘汰策略，吞吐量降低怎么辦？
那就將第二次刪除作為異步的。自己起一個(gè)線程，異步刪除。這樣，寫的請求就不用沉睡一段時(shí)間再返回。這么做，加大吞吐量。
第二次刪除，如果刪除失敗怎么辦？
這是個(gè)非常好的問題，因?yàn)榈诙蝿h除失敗，就會(huì)出現(xiàn)如下情形。還是有兩個(gè)請求，一個(gè)請求A進(jìn)行更新操作，另一個(gè)請求B進(jìn)行查詢操作，為了方便，假設(shè)是單庫：
- 請求A進(jìn)行寫操作，刪除緩存；
- 請求B查詢發(fā)現(xiàn)緩存不存在；
- 請求B去數(shù)據(jù)庫查詢得到舊值；
- 請求B將舊值寫入緩存；
- 請求A將新值寫入數(shù)據(jù)庫；
- 請求A試圖去刪除請求B寫入對緩存值，結(jié)果失敗了。
這也就是說，如果第二次刪除緩存失敗，會(huì)再次出現(xiàn)緩存和數(shù)據(jù)庫不一致的問題。
如何解決呢？
具體解決方案，且看筆者下文對第三種更新策略的解析。
三、先更新數(shù)據(jù)庫，再刪除緩存
國外提出了一個(gè)緩存更新套路，名為《Cache-Aside pattern》[1]，其中就指出：
- 失效：應(yīng)用程序先從cache取數(shù)據(jù)，沒有得到，則從數(shù)據(jù)庫中取數(shù)據(jù)，成功后，放到緩存中；
- 命中：應(yīng)用程序從cache中取數(shù)據(jù)，取到后返回；
- 更新：先把數(shù)據(jù)存到數(shù)據(jù)庫中，成功后，再讓緩存失效。
另外， Facebook也在論文《Scaling Memcache at Facebook》[2]中提出，他們用的也是先更新數(shù)據(jù)庫，再刪緩存的策略。
這種情況不存在并發(fā)問題么？
不是的。假設(shè)這會(huì)有兩個(gè)請求，一個(gè)請求A做查詢操作，一個(gè)請求B做更新操作，那么會(huì)有如下情形產(chǎn)生：
- 緩存剛好失效；
- 請求A查詢數(shù)據(jù)庫，得一個(gè)舊值；
- 請求B將新值寫入數(shù)據(jù)庫；
- 請求B刪除緩存；
- 請求A將查到的舊值寫入緩存。
如果發(fā)生上述情況，確實(shí)是會(huì)發(fā)生臟數(shù)據(jù)。
然而，發(fā)生這種情況的概率又有多少？
發(fā)生上述情況有一個(gè)先天性條件，就是步驟3的寫數(shù)據(jù)庫操作比步驟2的讀數(shù)據(jù)庫操作耗時(shí)更短，才有可能使得步驟4先于步驟5。可是，大家想想，數(shù)據(jù)庫的讀操作的速度遠(yuǎn)快于寫操作的（不然做讀寫分離干嘛，做讀寫分離的意義就是因?yàn)樽x操作比較快，耗資源少），因此步驟3耗時(shí)比步驟2更短，這一情形很難出現(xiàn)。
假設(shè)，有人非要抬杠，有強(qiáng)迫癥，一定要解決怎么辦？
如何解決上述并發(fā)問題？
首先，給緩存設(shè)有效時(shí)間是一種方案。其次，采用策略二里給出的異步延時(shí)刪除策略，保證讀請求完成以后，再進(jìn)行刪除操作。
還有其他造成不一致的原因么？
有的，這也是緩存更新策略二和緩存更新策略三都存在的一個(gè)問題，如果刪緩存失敗了怎么辦，那不是會(huì)有不一致的情況出現(xiàn)么。比如一個(gè)寫數(shù)據(jù)請求，然后寫入數(shù)據(jù)庫了，刪緩存失敗了，這會(huì)就出現(xiàn)不一致的情況了。這也是緩存更新策略二里留下的最后一個(gè)疑問。
如何解決？
提供一個(gè)保障的重試機(jī)制即可，這里給出兩套方案。
- 方案一：
如下圖所示：
流程如下所示：
- 更新數(shù)據(jù)庫數(shù)據(jù)；
- 緩存因?yàn)榉N種問題刪除失??；
- 將需要?jiǎng)h除的key發(fā)送至消息隊(duì)列；
- 自己消費(fèi)消息，獲得需要?jiǎng)h除的key；
- 繼續(xù)重試刪除操作，直到成功。
然而，該方案有一個(gè)缺點(diǎn)，對業(yè)務(wù)線代碼造成大量的侵入。于是有了方案二，在方案二中，啟動(dòng)一個(gè)訂閱程序去訂閱數(shù)據(jù)庫的binlog，獲得需要操作的數(shù)據(jù)。在應(yīng)用程序中，另起一段程序，獲得這個(gè)訂閱程序傳來的信息，進(jìn)行刪除緩存操作。
- 方案二：
流程如下圖所示：
- 更新數(shù)據(jù)庫數(shù)據(jù)；
- 數(shù)據(jù)庫會(huì)將操作信息寫入binlog日志當(dāng)中；
- 訂閱程序提取出所需要的數(shù)據(jù)以及key；
- 另起一段非業(yè)務(wù)代碼，獲得該信息；
- 嘗試刪除緩存操作，發(fā)現(xiàn)刪除失?。?/li>
- 將這些信息發(fā)送至消息隊(duì)列；
- 重新從消息隊(duì)列中獲得該數(shù)據(jù)，重試操作。
備注說明：上述的訂閱binlog程序在MySQL中有現(xiàn)成的中間件叫Canal，可以完成訂閱binlog日志的功能。至于Oracle中，筆者目前不清楚有沒有現(xiàn)成中間件可以使用。另外，重試機(jī)制，筆者采用的是消息隊(duì)列的方式。如果對一致性要求不是很高，直接在程序中另起一個(gè)線程，每隔一段時(shí)間去重試即可，這些大家可以靈活自由發(fā)揮，只是提供一個(gè)思路。
本文其實(shí)是對目前互聯(lián)網(wǎng)中已有的一致性方案，進(jìn)行了一個(gè)總結(jié)。對于先刪緩存、再更新數(shù)據(jù)庫的更新策略，還有方案提出維護(hù)一個(gè)內(nèi)存隊(duì)列的方式，筆者看了一下，覺得實(shí)現(xiàn)異常復(fù)雜，沒有必要，因此沒有在文中給出。最后，希望大家有所收獲。
七、應(yīng)對緩存穿透和緩存雪崩問題
關(guān)于“如何應(yīng)對緩存穿透和緩存雪崩”這兩個(gè)問題，說句實(shí)在話，一般中小型傳統(tǒng)軟件企業(yè)很難碰到。如果有大并發(fā)的項(xiàng)目，流量有幾百萬左右，這兩個(gè)問題一定要深刻考慮：
1、應(yīng)對緩存穿透
緩存穿透，即黑客故意去請求緩存中不存在的數(shù)據(jù)，導(dǎo)致所有的請求都懟到數(shù)據(jù)庫上，從而數(shù)據(jù)庫連接異常。
解決方案：
- 利用互斥鎖，緩存失效的時(shí)候，先去獲得鎖，得到鎖了，再去請求數(shù)據(jù)庫，沒得到鎖，則休眠一段時(shí)間重試；
- 采用異步更新策略，無論Key是否取到值，都直接返回。Value值中維護(hù)一個(gè)緩存失效時(shí)間，緩存如果過期，異步起一個(gè)線程去讀數(shù)據(jù)庫，更新緩存，需要做緩存預(yù)熱（項(xiàng)目啟動(dòng)前，先加載緩存）操作；
- 提供一個(gè)能迅速判斷請求是否有效的攔截機(jī)制，比如利用布隆過濾器，內(nèi)部維護(hù)一系列合法有效的Key，迅速判斷出，請求所攜帶的Key是否合法有效，如果不合法，則直接返回。
2、應(yīng)對緩存雪崩
緩存雪崩，即緩存同一時(shí)間大面積的失效，這個(gè)時(shí)候又來了一波請求，結(jié)果請求都懟到數(shù)據(jù)庫上，從而導(dǎo)致數(shù)據(jù)庫連接異常。
解決方案：
- 給緩存的失效時(shí)間加上一個(gè)隨機(jī)值，避免集體失效；
- 使用互斥鎖，但是該方案吞吐量明顯下降了；
- 雙緩存。我們有兩個(gè)緩存，緩存A和緩存B。緩存A的失效時(shí)間為20分鐘，緩存B不設(shè)失效時(shí)間，自己做緩存預(yù)熱操作。然后細(xì)分以下幾個(gè)小點(diǎn)：a. 從緩存A讀數(shù)據(jù)庫，有則直接返回；b. A 沒有數(shù)據(jù)，直接從B讀數(shù)據(jù)，直接返回，并且異步啟動(dòng)一個(gè)更新線程；c. 更新線程同時(shí)更新緩存A和緩存B。
八、如何解決Redis并發(fā)競爭Key問題
這個(gè)問題大致就是同時(shí)有多個(gè)子系統(tǒng)去Set一個(gè)Key。這個(gè)時(shí)候要注意什么呢？本人提前百度了一下，發(fā)現(xiàn)大家思考的答案基本都是推薦用Redis事務(wù)機(jī)制。但本人不推薦使用Redis的事務(wù)機(jī)制。因?yàn)槲覀兊纳a(chǎn)環(huán)境，基本都是Redis集群環(huán)境，做了數(shù)據(jù)分片操作。你一個(gè)事務(wù)中有涉及到多個(gè)Key操作的時(shí)候，這多個(gè)Key不一定都存儲(chǔ)在同一個(gè)Redis-Server上。因此，Redis的事務(wù)機(jī)制，十分雞肋。
解決方法如下：
如果對這個(gè)Key操作不要求順序
這種情況下，準(zhǔn)備一個(gè)分布式鎖，大家去搶鎖，搶到鎖就做Set操作即可，比較簡單。
如果對這個(gè)Key操作要求順序
假設(shè)有一個(gè)Key1，系統(tǒng)A需要將Key1設(shè)置為ValueA，系統(tǒng)B需要將Key1設(shè)置為ValueB，系統(tǒng)C需要將Key1設(shè)置為ValueC。期望按照Key1的Value值按照 ValueA→ValueB→ValueC的順序變化。這種時(shí)候我們在數(shù)據(jù)寫入數(shù)據(jù)庫的時(shí)候，需要保存一個(gè)時(shí)間戳。假設(shè)時(shí)間戳如下：
- 系統(tǒng)A Key 1 {ValueA 3:00}
- 系統(tǒng)B Key 1 {ValueB 3:05}
- 系統(tǒng)C Key 1 {ValueC 3:10}
那么，假設(shè)這會(huì)系統(tǒng)B先搶到鎖，將Key1設(shè)置為{ValueB 3:05}。接下來系統(tǒng)A搶到鎖，發(fā)現(xiàn)自己的ValueA的時(shí)間戳早于緩存中的時(shí)間戳，那就不做Set操作了。以此類推。
其他方法，比如利用隊(duì)列，將Set方法變成串行訪問也可以?？傊?，靈活變通。
完畢！~?。?/p>
