分布式系統下，資料庫和快取本來就無法保證強一致性，因為資料庫+快取的操作並不是原子操作，所以在服務過程中，我們可以忍受一段時間內的資料不一致，但是一定要保證最終一致性。
而一般來說，有三種更新策略：
這絕對不是個好方法，考慮這麼一種情況：
當更新快取成功，而更新資料庫失敗時，就直接造成了資料不一致。所以說這種策略幾乎沒啥人會使用
這也不是個好辦法，考慮這麼一種情況：
1.執行緒1將資料庫更新為a，執行緒2將資料庫更新b
2.執行緒2將快取更新為b，執行緒1將快取更新為a
那麼這會造成不一致：資料庫中，b把a覆蓋了（這是正確的邏輯），但是在快取中，a把b覆蓋了。就會造成資料不一致了。造成這個問題的罪魁禍首就是整個操作是非原子性的，有執行緒安全問題。
再考慮這麼一種情況：如果在乙個讀多寫少的場景，資料的更新非常頻繁(包括資料庫中和快取中)，有可能快取中的資料被頻繁更新，但是有一些資料壓根就從來沒有被訪問過，然後又被新值覆蓋了，這樣就會造成浪費。
這是一種比較常用的方法。如果淘汰快取成功，而更新資料庫失敗，這只會稍微降低快取的快取的命中率。相比於不一致性，這是可以接受了。
當然這個方法也無法完全保證一致性，考慮這樣一種情況：當快取淘汰之後，開始執行資料庫更新工作，但是這個操作還沒做完，就有另乙個讀請求落在了資料庫上，讀到了舊值，並把舊值放進了快取中，那麼就會出現快取資料庫不一致了。
上面的情況是在單機情況下，在讀寫分離，也就是擁有主從伺服器的架構中，這種情況更明顯：淘汰了快取，主伺服器完成更新，但是主從同步還未完成，在這期間，讀請求落在了從伺服器上，由於主從同步還未完成，就會讀到舊值，並且放到了快取中，也就造成了資料不一致
解決方法：
如果更新資料庫失敗，則直接返回，不會有任何影響；若更新資料庫成功，淘汰快取失敗，此時會直接造成資料不一致。當然，及時全部操作成功，也會造成資料不一致，比如：
執行緒1查詢乙個舊值，然後執行緒2更新資料為新值，然後把快取刪除，執行緒1才姍姍來遲地把快取更新為舊值。這樣就造成資料不一致。
解決方法：同樣使用延時雙刪策略
快取與資料庫一致性保證
本文主要討論這麼幾個問題 1 啥時候資料庫和快取中的資料會不一致 2 不一致優化思路 3 如何保證資料庫與快取的一致性 當資料發生變化時，先淘汰快取，再修改資料庫 這個點是大家討論的最多的。上篇文章得出這個結論的依據是，由於操作快取與運算元據庫不是原子的，非常有可能出現執行失敗。假設先寫資料庫，再淘...
資料庫快取如何保證一致性
先新資料庫再更新快取。問題 更新資料庫後，更新快取時，如果資料庫資料又變更了，那快取裡就更新成髒資料了。先刪除快取，然後再更新資料庫。刪除快取後，進行更新資料庫時，如果乙個請求來了，它在快取中沒命中，就會去資料庫中查詢，並把查到的資料更新到快取裡，隨後資料庫才更新完畢，這就導致快取裡的資料又成為髒資...
快取與資料庫一致性
此時系統的讀寫流量很小，這個時候所有的讀寫操作都在主庫 此時，從庫的角色只是作為災備。風險分析 從資料一致性的角度來看沒有任何問題，所有讀寫操作都在主庫 隨著業務的前進和流量的激增，會出現大表和資料庫寫入效能下降的問題。我們可以通過分庫的方式，提公升資料庫單機的qps壓下來 通過分表的方式，降低單錶...