一、Redis三種常用的緩存讀寫策略

Redis有三種讀寫策略分別是：旁路緩存模式策略、讀寫穿透策略、異步緩存寫入策略。

這三種緩存讀寫策略各有優(yōu)勢(shì)，不存在最佳，需要我們根據(jù)實(shí)際的業(yè)務(wù)場(chǎng)景選擇最合適的。

二、旁路緩存模式（Cache Aside Pattern）

旁路緩存模式是我們平時(shí)使用比較多的一個(gè)緩存讀寫模式，比較適合讀請(qǐng)求比較多的場(chǎng)景。

旁路緩存模式中服務(wù)端需要同時(shí)維護(hù)DB和Cache，并且是以DB的結(jié)果為準(zhǔn)。

讀寫步驟

寫：

• 先更新DB。
• 然后直接刪除cache。

如下圖：

讀：

• 從cache中讀取數(shù)據(jù)，讀取到就直接返回。
• cache中讀取不到的話，就從DB讀取返回。
• 再把數(shù)據(jù)寫到cache中。

如下圖：

自我思考

思考這樣子的一個(gè)問題：“如果在寫數(shù)據(jù)的過程中，可以先刪除cache，再更新DB嗎？ ”

答案： 答案肯定是不行的，因?yàn)檫@樣子可能造成數(shù)據(jù)庫和緩存數(shù)據(jù)不一致的問題，比如這個(gè)時(shí)候有一個(gè)數(shù)據(jù)在DB和緩存都為100，請(qǐng)求1需要將這個(gè)數(shù)據(jù)更新寫成200，如果先刪除換出再更新數(shù)據(jù)庫的話，在請(qǐng)求1已經(jīng)刪除緩存但是數(shù)據(jù)庫還沒寫完的時(shí)候，有一個(gè)請(qǐng)求2讀取數(shù)據(jù)，首先去緩存讀取，發(fā)現(xiàn)緩存被刪除了，然后去數(shù)據(jù)庫讀取得到100（這個(gè)時(shí)候請(qǐng)求1還沒寫完）再寫入緩存，這個(gè)時(shí)候請(qǐng)求1寫完了，這個(gè)時(shí)候數(shù)據(jù)庫里數(shù)據(jù)為200，緩存里為100，不一致。

可以簡(jiǎn)單描述為：

請(qǐng)求1先把cache中的數(shù)據(jù)刪除 -> 請(qǐng)求2從DB中讀取數(shù)據(jù) -> 請(qǐng)求1再把DB中的數(shù)據(jù)更新

緊接著思考：“在寫數(shù)據(jù)的過程中，如果先寫B(tài)D，再刪除cache就不會(huì)造成數(shù)據(jù)不一致了嗎？ ”

答案： 理論上來說還是會(huì)出現(xiàn)數(shù)據(jù)不一致的問題，不過概率很小，因?yàn)榫彺娴膶懭胨俣仁潜葦?shù)據(jù)庫寫入速度快很多。

比如請(qǐng)求1先讀數(shù)據(jù)A，請(qǐng)求2隨后寫數(shù)據(jù)A，并且數(shù)據(jù)A不在緩存中存在的話就會(huì)去數(shù)據(jù)庫讀取，讀取完請(qǐng)求2再更新完并刪除緩存，然后請(qǐng)求1把數(shù)據(jù)A寫入緩存，這個(gè)時(shí)候數(shù)據(jù)庫和緩存就不一致了。

這個(gè)過程可以簡(jiǎn)單的描述為：

請(qǐng)求1從DB讀取數(shù)據(jù)A -> 請(qǐng)求2寫更新數(shù)據(jù)A到數(shù)據(jù)庫再刪除cache中的A數(shù)據(jù) -> 請(qǐng)求1將數(shù)據(jù)A寫入緩存

缺點(diǎn)

• 首次請(qǐng)求的數(shù)據(jù)一定不在cache的問題

  解決辦法：可以將熱點(diǎn)數(shù)據(jù)提前寫入cache中。

• 寫操作比較頻繁的話導(dǎo)致cache中的數(shù)據(jù)會(huì)被頻繁的刪除，這樣會(huì)影響緩存命中率。

  解決辦法：

  • 數(shù)據(jù)庫和緩存強(qiáng)一直場(chǎng)景：更新DB的時(shí)候同樣更新cache，不過需要加一個(gè)鎖/分布式鎖來保證更新cache的時(shí)候不存在線程安全問題。
  • 可以短暫的允許數(shù)據(jù)庫和緩存數(shù)據(jù)不一致的場(chǎng)景：更新DB的時(shí)候同樣更新cache，但是給緩存加一個(gè)比較短的過期時(shí)間，這樣的話就可以保證即使數(shù)據(jù)不一致的話影響也比較小。

三、讀寫穿透（Read/Write Through Pattern）

讀寫穿透中服務(wù)端把cache視為主要數(shù)據(jù)存儲(chǔ)，從中讀取數(shù)據(jù)并將數(shù)據(jù)寫入其中。cache服務(wù)負(fù)責(zé)將此數(shù)據(jù)讀取和寫入DB，從而減輕應(yīng)用程序的職責(zé)。

讀寫步驟

寫：

• 先查cache，cache中不存在，直接更新DB。
• cache中存在，則先更新cache，然后cache服務(wù)自己更新DB（同時(shí)更新DB和cache）。

如下圖：

讀：

• 先從cache中讀取數(shù)據(jù)，讀取到直接返回。
• 從cache中讀取不到，則先從DB加載寫入到cache后返回響應(yīng)。

如下圖：

讀寫穿透實(shí)際是在旁路緩存之上進(jìn)行了封裝。在旁路緩存下，發(fā)生讀請(qǐng)求的時(shí)候，如果cache中不存在對(duì)應(yīng)的數(shù)據(jù)，是由客戶端自己負(fù)責(zé)把數(shù)據(jù)寫入cache，而讀寫穿透則是cache服務(wù)自己來寫入緩存，這對(duì)客戶端是透明的。

和旁路緩存一樣，讀寫穿透也存在首次請(qǐng)求數(shù)據(jù)一定不在cache中的問題，對(duì)于熱點(diǎn)數(shù)據(jù)可以提前寫入緩存中。

四、異步緩存寫入（Write Behind Pattern）

異步緩存寫入和讀寫穿透很相似，兩者都是由cache服務(wù)來負(fù)責(zé)cache和DB的讀寫。

兩者最大的不同點(diǎn)就是：讀寫穿透是同步更新DB和cache，而異步緩存寫入則是只更新cache，不直接更新DB，而是改為異步批量的方式更新DB。

很明顯，這種方式對(duì)數(shù)據(jù)一致性帶來了更大的挑戰(zhàn)，比如cache數(shù)據(jù)可能還沒異步更新DB，cache服務(wù)可能就掛了。

這種策略在我們平時(shí)開發(fā)過程中也非常少見，但是不代表它的應(yīng)用場(chǎng)景少，比如消息隊(duì)列中消息的異步寫入磁盤、MySQL的InnoDB Buffer Pool機(jī)制都用到了這種策略。

異步緩存寫入的寫性能非常高，非常適合寫數(shù)據(jù)經(jīng)常變化又對(duì)數(shù)據(jù)一致性要求沒那么高的場(chǎng)景下使用，比如瀏覽量、點(diǎn)贊量等。

參考：javaguide.cn/database/re…

到此這篇關(guān)于Redis三種常用的緩存讀寫策略的文章就介紹到這了,更多相關(guān)Redis緩存讀寫策略內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！