Redis緩存更新策略

本文整理自黑馬程式員相關資料

業務場景需求：

• 在基本不會更新數據的情況下可以使用記憶體淘汰機制
• 在頻繁更新數據的情況下可以使用主動更新，並以超時剔除作為兜底方案。

主動更新的三種方法

• Cache Aside Pattern：由緩存的調用者，在更新資料庫的同時更新緩存

• Read/Write Through Pattern：緩存和資料庫整合為一個服務，由服務來維護一致性。調用者調用該服務，無需關心緩存一致性問題。

  優點：整合的服務保證了數據的一致性

  缺點：維護和開放成本高

• Write Behind Caching Pattern：調用者只操作緩存，由其他線程非同步的將緩存數據持久化到資料庫，最終保持一致。

  優點：非同步更新緩存數據，效率高。例如緩存多次更新，但是更新到的緩存並沒有被使用，多次將數據持久化到資料庫就相當於進行了無用的操作，非同步更新相當於將前幾次的更新合併為一次更新，因而提高了效率。

  缺點：無法保證一致性，維護成本高

目前主流使用的Redis緩存主動更新的方法是Cache Aside Pattern

操作緩存和資料庫時需要考慮的三個問題

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

   • 更新緩存：每次更新資料庫都更新緩存，無效寫操作較多
   • 刪除緩存：更新資料庫時讓緩存失效，查詢時再更新緩存

2. 如何保證緩存與資料庫的操作的同時成功或者失敗

   • 對於單體系統：將緩存與資料庫操作放在一個事務中
   • 對於分散式系統：利用TCC等分散式事務方案

3. 先操作緩存還是先操作資料庫

   • 先刪除緩存，再操作資料庫

   

   • 先操作資料庫，再刪除緩存

   

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