快捷導(dǎo)航

淺談Redis緩存更新策略

更新時(shí)間：2022年08月03日 08:45:48 作者：腳踏實(shí)地?仰望星空

這篇文章主要介紹了Redis緩存更新策略的相關(guān)資料，講解的十分細(xì)致，有需要的小伙伴可以參考下

	內(nèi)存淘汰	超時(shí)剔除	主動(dòng)更新
說明	不用自己維護(hù)，利用Redis的內(nèi)存淘汰機(jī)制，當(dāng)內(nèi)存不足時(shí)自動(dòng)淘汰部分?jǐn)?shù)據(jù)。下次查詢時(shí)更新緩存	給緩存數(shù)據(jù)添加TTL時(shí)間，到期后自動(dòng)刪除緩存，下次查詢時(shí)更新緩存	編寫業(yè)務(wù)邏輯，在修改數(shù)據(jù)的同時(shí)，更新緩存
一致性	差	一般	好
維護(hù)成本	無	低	高

業(yè)務(wù)場(chǎng)景需求：

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

主動(dòng)更新的三種方法

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

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

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

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

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

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

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

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

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

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

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

您可能感興趣的文章: