Redis快取更新策略
本文整理自黑馬程式員相關資料
| 記憶體淘汰 | 超時剔除 | 主動更新 | |
|---|---|---|---|
| 說明 | 不用自己維護，利用Redis的記憶體淘汰機制，當記憶體不足時自動淘汰部分資料，下次查詢時更新快取 | 給快取資料添加TTL時間，到期后自動洗掉快取，下次查詢時更新快取 | 撰寫業務邏輯，在修改資料的同時，更新快取 |
| 一致性 | 差 | 一般 | 好 |
| 維護成本 | 無 | 低 | 高 |
業務場景需求：
- 在基本不會更新資料的情況下可以使用記憶體淘汰機制
- 在頻繁更新資料的情況下可以使用主動更新，并以超時剔除作為兜底方案，
主動更新的三種方法
-
Cache Aside Pattern：由快取的呼叫者，在更新資料庫的同時更新快取
-
Read/Write Through Pattern：快取和資料庫整合為一個服務，由服務來維護一致性，呼叫者呼叫該服務，無需關心快取一致性問題，
優點：整合的服務保證了資料的一致性
缺點：維護和開放成本高
-
Write Behind Caching Pattern：呼叫者只操作快取，由其他執行緒異步的將快取資料持久化到資料庫，最終保持一致，
優點：異步更新快取資料，效率高，例如快取多次更新，但是更新到的快取并沒有被使用，多次將資料持久化到資料庫就相當于進行了無用的操作，異步更新相當于將前幾次的更新合并為一次更新，因而提高了效率，
缺點：無法保證一致性，維護成本高
目前主流使用的Redis快取主動更新的方法是Cache Aside Pattern
操作快取和資料庫時需要考慮的三個問題
-
洗掉快取還是更新快取？
- 更新快取：每次更新資料庫都更新快取，無效寫操作較多
- 洗掉快取：更新資料庫時讓快取失效，查詢時再更新快取
-
如何保證快取與資料庫的操作的同時成功或者失敗
- 對于單體系統：將快取與資料庫操作放在一個事務中
- 對于分布式系統：利用TCC等分布式事務方案
-
先操作快取還是先操作資料庫
- 先洗掉快取，再操作資料庫
- 先操作資料庫，再洗掉快取
如上圖所示，兩種方案在多執行緒的情況下都會產生資料不一致的問題，但是在先操作資料庫再洗掉快取的情況下，要發生資料不一致的問題，需要在快取寫入之前完成更新資料庫和洗掉快取的操作，而寫入快取的耗時非常短，因而發生的概率相對于另一種方案更低，所以選擇先操作資料庫，再洗掉快取，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/499126.html
標籤：NoSQL
上一篇：Redis常見使用場景
下一篇：快取穿透，快取雪崩，快取擊穿