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