Redis項目總結--緩存更新策略

1.更新策略

低一致性場景選記憶體淘汰，高一致性場景選主動更新，也可以和超時剔除結合使用

2.主動更新的三種方案（一般用方案一）

方案一：在更新資料庫 的同時更新緩存。

方案二：緩存與資料庫整合為一個服務，由服務來維護一致性，調用者調用該服務，無需關心緩存一致性問題。

• 優點：保證了數據的一致性
• 缺點：開發成本高

方案三：調用者只操作緩存，由其他線程非同步將緩存數據持久化到資料庫。

• 優點：非同步更新緩存數據，效率高。兩次非同步更新之間，對一個數據進行了多次修改，最終只有最後一次的更新有效，相當於將多次更新合併為一次。
• 缺點：維護成本高，一致性和可靠性存在問題。數據變動後到下一次非同步更新前數據不一致。若出現宕機則數據丟失。

3.主動更新方案一操作緩存和資料庫的三個問題

(1)刪緩存還是更新緩存（一般選刪除緩存）

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

(2)如何保證緩存和資料庫操作同時成功或失敗

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

(3)先操作緩存還是先操作資料庫（會引發兩種不同的線程安全問題）

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

4.緩存和資料庫操作順序引發的線程安全問題

一般更新的操作比查詢和寫入緩慢，第二種操作發生異常的概率比第一種操作低，所以一般使用先操作資料庫再刪緩存

(1)先刪緩存再操作資料庫

正常情況：

異常情況：

(2)先操作資料庫再刪緩存

正常情況：

異常情況：

5.最終方案

綜上，一般選用主動更新+超時剔除

1. 根據id查詢店鋪時，緩存未命中則查詢資料庫，將資料庫結果寫入緩存，並設置超時時間。
2. 根據id修改店鋪時，先修改資料庫再修改緩存。