業(yè)務場景需求：

• 在基本不會更新數(shù)據(jù)的情況下可以使用內存淘汰機制
• 在頻繁更新數(shù)據(jù)的情況下可以使用主動更新，并以超時剔除作為兜底方案。

主動更新的三種方法

• Cache Aside Pattern：由緩存的調用者，在更新數(shù)據(jù)庫的同時更新緩存
• Read/Write Through Pattern：緩存和數(shù)據(jù)庫整合為一個服務，由服務來維護一致性。調用者調用該服務，無需關心緩存一致性問題。
  優(yōu)點：整合的服務保證了數(shù)據(jù)的一致性
  缺點：維護和開放成本高
• Write Behind Caching Pattern：調用者只操作緩存，由其他線程異步的將緩存數(shù)據(jù)持久化到數(shù)據(jù)庫，最終保持一致。
  優(yōu)點：異步更新緩存數(shù)據(jù)，效率高。例如緩存多次更新，但是更新到的緩存并沒有被使用，多次將數(shù)據(jù)持久化到數(shù)據(jù)庫就相當于進行了無用的操作，異步更新相當于將前幾次的更新合并為一次更新，因而提高了效率。
  缺點：無法保證一致性，維護成本高
• 目前主流使用的Redis緩存主動更新的方法是Cache Aside Pattern

操作緩存和數(shù)據(jù)庫時需要考慮的三個問題

1.刪除緩存還是更新緩存？

• 更新緩存：每次更新數(shù)據(jù)庫都更新緩存，無效寫操作較多
• 刪除緩存：更新數(shù)據(jù)庫時讓緩存失效，查詢時再更新緩存

2.如何保證緩存與數(shù)據(jù)庫的操作的同時成功或者失敗

• 對于單體系統(tǒng)：將緩存與數(shù)據(jù)庫操作放在一個事務中
• 對于分布式系統(tǒng)：利用TCC等分布式事務方案

3.先操作緩存還是先操作數(shù)據(jù)庫

先刪除緩存，再操作數(shù)據(jù)庫

先操作數(shù)據(jù)庫，再刪除緩存

如上圖所示，兩種方案在多線程的情況下都會產(chǎn)生數(shù)據(jù)不一致的問題。但是在先操作數(shù)據(jù)庫再刪除緩存的情況下，要發(fā)生數(shù)據(jù)不一致的問題，需要在緩存寫入之前完成更新數(shù)據(jù)庫和刪除緩存的操作，而寫入緩存的耗時非常短。因而發(fā)生的概率相對于另一種方案更低。所以選擇先操作數(shù)據(jù)庫，再刪除緩存。

到此這篇關于淺談Redis緩存更新策略的文章就介紹到這了,更多相關Redis緩存更新策略內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論