1）、無論是雙寫模式還是失效模式，都會導致快取的不一致問題。即多個例項同時更新會出事。怎麼辦？
解決方案
a: 如果是使用者緯度資料（訂單資料、使用者資料），這種併發機率非常小，不用考慮這個問題，快取資料加上過期時間，每隔一段時間觸發讀的主動更新即可
b: 如果是選單，商品介紹等基礎資料，也可以去使用canal訂閱binlog的方式
c: 快取資料+過期時間也足夠解決大部分業務對於快取的要求
d: 通過加鎖保證併發讀寫，寫寫的時候按順序排好隊。讀讀無所謂。所以適合使用讀寫鎖
e: 延遲雙刪策略【增、刪、改等操作時需要考慮快取與資料庫資料一致性問題】
1 a redis .del(record)
2 a db update(record)
3 thread.sleep(ms)； 休眠一定時間。
4 a redis .del(record)
我們能放入快取的資料本就不應該是實時性、一致性要求超高的。所以快取資料的時候加上過期時間，保 證每天拿到當前最新資料即可。
我們不應該過度設計，增加系統的複雜性
遇到實時性、一致性要求高的資料，就應該查資料庫，即使慢點。
資料庫 快取資料一致性
1 不推薦更新快取 建議刪除快取 2 採用延時雙刪 先刪快取，後更新資料庫，延時再刪一次快取 但是會存在問題 改庫後延時時間內的資料可能是舊資料 如果業務場景要求，改庫成功就不能使用舊資料，可以採用如下優化方案 新增乙個快取型別，記錄key是否被更新過，並且設定自動過期時間 在訪問的時候，先查詢ke...
Redis快取與資料庫資料一致性
寫流程 先刪除快取，刪除之後再更新db，再非同步將資料刷回快取。如果先更新資料庫再更新快取，更新資料庫時，程式訪問快取時還是舊的資料。讀流程 先讀快取，如果快取沒讀到，則去讀db，之後再非同步將資料刷回快取。缺點 容災不足 第一步del快取失敗 如果繼續執行，那麼從 更新完db 到非同步 重新整理快...
如何保證快取與資料庫資料一致性
重點文章 你只要用快取，就可能會涉及到快取與資料庫雙儲存雙寫，你只要是雙寫，就一定會有資料一致性的問題，那麼你如何解決一致性問題？一般來說，就是如果你的系統不是嚴格要求快取 資料庫必須一致性的話，快取可以稍微的跟資料庫偶爾有不一致的情況，最好不要做這個方案，讀請求和寫請求序列化，串到乙個記憶體佇列裡...