業務場景需求：

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

主動更新的三種方法

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

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

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

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

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

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

3.先操作緩存還是先操作數據庫

先刪除緩存，再操作數據庫

先操作數據庫，再刪除緩存

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