Redis項目總結--緩存更新策略 1.更新策略 | | 記憶體淘汰 | 超時剔除 | 主動更新 | | : : | : : | : : | : : | | 說明 | 不用自己維護，利用Redis記憶體淘汰機制，記憶體不足時自動淘汰部分數據，下次查詢時更新緩存 | 給緩存數據添加過期時間，到期刪除，下次查 ...
Redis項目總結--緩存更新策略
1.更新策略
| 記憶體淘汰 | 超時剔除 | 主動更新 | |
|---|---|---|---|
| 說明 | 不用自己維護，利用Redis記憶體淘汰機制，記憶體不足時自動淘汰部分數據，下次查詢時更新緩存 | 給緩存數據添加過期時間，到期刪除，下次查詢時更新緩存 | 編寫業務邏輯，在修改資料庫的同時更新緩存 |
| 一致性 | 差 | 一般(取決於過期時間的長短) | 好 |
| 維護成本 | 無 | 低 | 高 |
低一致性場景選記憶體淘汰，高一致性場景選主動更新，也可以和超時剔除結合使用
2.主動更新的三種方案（一般用方案一）
方案一：在更新資料庫 的同時更新緩存。
方案二：緩存與資料庫整合為一個服務，由服務來維護一致性，調用者調用該服務，無需關心緩存一致性問題。
- 優點：保證了數據的一致性
- 缺點：開發成本高
方案三：調用者只操作緩存，由其他線程非同步將緩存數據持久化到資料庫。
- 優點：非同步更新緩存數據，效率高。兩次非同步更新之間，對一個數據進行了多次修改，最終只有最後一次的更新有效，相當於將多次更新合併為一次。
- 缺點：維護成本高，一致性和可靠性存在問題。數據變動後到下一次非同步更新前數據不一致。若出現宕機則數據丟失。
3.主動更新方案一操作緩存和資料庫的三個問題
(1)刪緩存還是更新緩存（一般選刪除緩存）
- 更新緩存：每次更新資料庫都更新緩存，無效寫操作多
- 刪除緩存：更新資料庫時讓緩存失效，查詢時再更新緩存
(2)如何保證緩存和資料庫操作同時成功或失敗
- 單體系統：將緩存與資料庫操作放到同一個事務
- 分散式系統：利用TCC等分散式事務事務方案
(3)先操作緩存還是先操作資料庫（會引發兩種不同的線程安全問題）
- 先刪緩存再操作資料庫
- 先操作資料庫再刪緩存
4.緩存和資料庫操作順序引發的線程安全問題
一般更新的操作比查詢和寫入緩慢，第二種操作發生異常的概率比第一種操作低，所以一般使用先操作資料庫再刪緩存
(1)先刪緩存再操作資料庫
正常情況：
異常情況：
(2)先操作資料庫再刪緩存
正常情況：
異常情況：
