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

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

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

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

旁路緩存模式是我們平時使用比較多的一個緩存讀寫模式，比較適合讀請求比較多的場景。

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

讀寫步驟

寫：

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

如下圖：

讀：

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

如下圖：

自我思考

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

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

可以簡單描述為：

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

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

答案： 理論上來說還是會出現(xiàn)數(shù)據(jù)不一致的問題，不過概率很小，因為緩存的寫入速度是比數(shù)據(jù)庫寫入速度快很多。

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

這個過程可以簡單的描述為：

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

缺點

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

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

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

  解決辦法：

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

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

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

讀寫步驟

寫：

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

如下圖：

讀：

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

如下圖：

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

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

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

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

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

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

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

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

參考：javaguide.cn/database/re…

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

最新評論