Redis專案總結--快取更新策略
1.更新策略
| 記憶體淘汰 | 超時剔除 | 主動更新 | |
|---|---|---|---|
| 說明 | 不用自己維護，利用Redis記憶體淘汰機制，記憶體不足時自動淘汰部分資料，下次查詢時更新快取 | 給快取資料添加過期時間，到期洗掉，下次查詢時更新快取 | 撰寫業務邏輯，在修改資料庫的同時更新快取 |
| 一致性 | 差 | 一般(取決于過期時間的長短) | 好 |
| 維護成本 | 無 | 低 | 高 |
低一致性場景選記憶體淘汰，高一致性場景選主動更新，也可以和超時剔除結合使用
2.主動更新的三種方案（一般用方案一）
方案一：在更新資料庫 的同時更新快取，
方案二：快取與資料庫整合為一個服務，由服務來維護一致性，呼叫者呼叫該服務，無需關心快取一致性問題，
- 優點：保證了資料的一致性
- 缺點：開發成本高
方案三：呼叫者只操作快取，由其他執行緒異步將快取資料持久化到資料庫，
- 優點：異步更新快取資料，效率高，兩次異步更新之間，對一個資料進行了多次修改，最終只有最后一次的更新有效，相當于將多次更新合并為一次，
- 缺點：維護成本高，一致性和可靠性存在問題，資料變動后到下一次異步更新前資料不一致，若出現宕機則資料丟失，
3.主動更新方案一操作快取和資料庫的三個問題
(1)刪快取還是更新快取（一般選洗掉快取）
- 更新快取：每次更新資料庫都更新快取，無效寫操作多
- 洗掉快取：更新資料庫時讓快取失效，查詢時再更新快取
(2)如何保證快取和資料庫操作同時成功或失敗
- 單體系統：將快取與資料庫操作放到同一個事務
- 分布式系統：利用TCC等分布式事務事務方案
(3)先操作快取還是先操作資料庫（會引發兩種不同的執行緒安全問題）
- 先刪快取再操作資料庫
- 先操作資料庫再刪快取
4.快取和資料庫操作順序引發的執行緒安全問題
一般更新的操作比查詢和寫入緩慢，第二種操作發生例外的概率比第一種操作低，所以一般使用先操作資料庫再刪快取
(1)先刪快取再操作資料庫
正常情況：
例外情況：
(2)先操作資料庫再刪快取
正常情況：
例外情況：
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/539577.html
標籤：其他
上一篇：全網最全的linux上docker安裝oracle的詳細檔案，遇到了n個問題，查了幾十篇文章，最侄訓總版，再有解決不了的,私聊我，我幫你解決