1、緩存更新策略

1.1、內存淘汰

說明：不用自己維護，利用Redis的內存淘汰機制，當內存不足時自動淘汰部分數據。下次查詢時更新緩存。
一致性：差
維護成本：無

1.2、超時剔除

說明：給緩存數據添加TTL（Time To Live）時間，到期后自動刪除緩存。下次查詢時更新緩存。
一致性：一般
維護成本：低

1.3、主動更新

編寫業務邏輯，在修改數據庫的同時，更新緩存
一致性：好
維護成本：高

2、業務場景：

• 低一致性需求：使用內存淘汰機制。例如店鋪類型的查詢緩存
• 高一致性需求：主動更新，并以超時剔除作為兜底方案。例如店鋪詳情查詢的緩存

3、主動更新在企業中業務實現有三種方式

3.1、Cache Aside Pattern

企業用的最多
由緩存的調用者，在更新數據庫的同時更新緩存

3.1.1、操作緩存和數據庫時有三個問題需要考慮：

3.1.1.1、刪除緩存還是更新緩存？

• 更新緩存：每次更新數據庫都更新緩存，無效寫操作較多
• 刪除緩存：更新數據庫時讓緩存失效，查詢時再更新緩存，一般會選擇刪除緩存的這個方案

3.1.1.2、如何保證緩存與數據庫的操作的同時成功或失敗？

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

3.1.1.3、先操作緩存還是先操作數據庫？

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

3.2、Read/Write Through Pattern

緩存與數據庫整合為一個服務，由服務來維護一致性。調用者調用該服務，無需關心緩存一致性問題。

3.3、Write Behind Caching Pattern

調用者只操作緩存，由其它線程異步的將緩存數據持久化到數據庫，保證最終一致。

4、緩存更新策略的最佳實踐方案：

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

5、讀操作

• 緩存命中則直接返回
• 緩存未命中則查詢數據庫，并寫入緩存，設定超時時間

6、寫操作：

• 先寫數據庫，然后再刪除緩存
• 要確保數據庫與緩存操作的原子性