緩存更新

緩存的更新是redis為了節(jié)約內(nèi)存而設(shè)計出來的東西，主要是因為內(nèi)存數(shù)據(jù)寶貴，當(dāng)我們向redis插入太多數(shù)據(jù)，此時就可能會導(dǎo)致緩存中的數(shù)據(jù)過多，所以redis會對部分?jǐn)?shù)據(jù)進(jìn)行更新，或者把它成為淘汰更合適。

1.redis的緩存更新的三種策略

1. 內(nèi)存淘汰
   • redis自動進(jìn)行，當(dāng)redis內(nèi)存達(dá)到咱們設(shè)定的max-memery的時候會自動觸發(fā)淘汰機制，淘汰調(diào)一些不重要的數(shù)據(jù)（自己可以設(shè)置策略方式）
2. 超時剔除
   • 當(dāng)我們給redis設(shè)置了過期時間ttl之后，redis會將超時的數(shù)據(jù)進(jìn)行刪除，方便咱們繼續(xù)使用緩存。
3. 主動更新
   • 我們可以手動條用方法把緩存刪掉，通常用于解決緩存和數(shù)據(jù)庫不一致問題。

主動更新有分三種方式：

1. 由緩存的調(diào)用者，在更新數(shù)據(jù)庫的同時更新緩存。
2. 緩存和數(shù)據(jù)庫整合為一個服務(wù)，由服務(wù)來維護(hù)一致性。調(diào)用者調(diào)用該服務(wù)（對外提供一個透明的服務(wù)），無需關(guān)系緩存一致性問題。
3. 調(diào)用者只操作緩存，有其他線程異步的將緩存持久化到數(shù)據(jù)庫，保證最終一致。（類似于數(shù)據(jù)庫的索引，一個索引更新在沒有提交事務(wù)時，修改了100次只有最后一次有效，但這會使效率降低。）

如果采用第一個方案，那么假設(shè)我們每次操作數(shù)據(jù)庫后，都操作緩存，但是中間如果沒有人查詢，那么這個更新動作實際上只有最后一次生效，中間的更新動作意義并不大，我們可以把緩存刪除，等待再次查詢時，將緩存中的數(shù)據(jù)加載出來

• 刪除緩存還是更新緩存？
  • 更新緩存：每次更新數(shù)據(jù)庫都更新緩存，無效寫操作較多
  • 刪除緩存：更新數(shù)據(jù)庫時讓緩存失效，查詢時再更新緩存
• 如何保證緩存與數(shù)據(jù)庫的操作的同時成功或失??？
  • 單體系統(tǒng)，將緩存與數(shù)據(jù)庫操作放在一個事務(wù)
  • 分布式系統(tǒng)，利用TCC等分布式事務(wù)方案
• 先操作緩存還是先操作數(shù)據(jù)庫？
  • 先刪除緩存，再操作數(shù)據(jù)庫 （第一種方案）
  • 先操作數(shù)據(jù)庫，再刪除緩存

應(yīng)該具體操作緩存還是操作數(shù)據(jù)庫，我們應(yīng)當(dāng)是先操作數(shù)據(jù)庫，再刪除緩存，原因在于，如果你選擇第一種方案，在兩個線程并發(fā)來訪問時，假設(shè)線程1先來，他先把緩存刪了，此時線程2過來，他查詢緩存數(shù)據(jù)并不存在，此時他寫入緩存，當(dāng)他寫入緩存后，線程1再執(zhí)行更新動作時，實際上寫入的就是舊的數(shù)據(jù)，新的數(shù)據(jù)被舊數(shù)據(jù)覆蓋了。

redis的讀寫是微秒級別的，但是數(shù)據(jù)庫的更新時遠(yuǎn)遠(yuǎn)比redis的讀寫慢的。

三者之間比較

2. 緩存更新策略的最佳實踐方案：

1. 低一致性需求：使用Redis自帶的內(nèi)存淘汰機制
2. 高一致性需求：主動更新，并以超時剔除作為兜底方案

• 讀操作：
  • 緩存命中則直接返回
  • 緩存未命中則查詢數(shù)據(jù)庫，并寫入緩存，設(shè)定超時時間
• 寫操作：
  • 先寫數(shù)據(jù)庫，然后再刪除緩存
  • 要確保數(shù)據(jù)庫與緩存操作的原子性

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

最新評論