為了提公升效能，快取在系統開發中具有普遍的應用。常見的模式是先查詢/更新db後再去更新快取，那麼如何保證db和快取的資料一致性的問題是實際開發中經常遇到的問題。這種場景下容易造成資料不一致的問題主要是快取雙寫。一、快取雙寫問題
先查詢或者更新db，然後再更新快取，這裡可能出現的一種不一致的情況是db更新或查詢成功，但是快取更新失敗了，這個不一致的問題可以通過重試更新快取的方式來解決，保證最終一致性。但是這個方案只適用於只有乙個更新快取的執行緒的場景。
如果有多個執行緒同時更新快取呢，也就是雙寫，比如查詢執行緒a查詢到資料後要更新快取，此時另乙個更新執行緒b在完成db的更新後也要更新快取，這個時候，執行緒a可能在查詢時db還沒有完成更新，查到的是老資料，如果最終執行緒a後於b更新快取，則快取中最終的資料則是舊的資料，就會出現db和快取資料不一致的情況。
二、解決方案
解決這個問題的關鍵是如何保證多個執行緒更新有序性，化並行為序列是解決這個問題的基本思路。在這裡我們可以考慮引入佇列的方式來解決，通過佇列來保證執行緒更新的有序性。
mq的選型比較建議使用訊息佇列，比如rabbitmq，rocketmq等，消費端保證只有乙個執行緒順序消費訊息即可。如果要增大吞吐量，可以使用多個佇列，每個佇列對應乙個消費者。使用訊息佇列可以充分利用其特性，比如訊息的持久化，訊息消費失敗後的重試等，可以更好的保證資料的最終一致性。
如何保證db與快取的資料一致性
為了提公升效能，快取在系統開發中具有普遍的應用。常見的模式是先查詢 更新db後再去更新快取，那麼如何保證db和快取的資料一致性的問題是實際開發中經常遇到的問題。這種場景下容易造成資料不一致的問題主要是快取雙寫。先查詢或者更新db，然後再更新快取，這裡可能出現的一種不一致的情況是db更新或查詢成功，但...
Redis 如何保證快取和資料一致性
不一致問題 缺點 如果在修改資料庫之後更新快取之前出現問題，出現資料不一致 解決方案 先刪除快取，再修改資料庫 缺點 如果在刪除快取之後修改資料庫之前，出現另乙個執行緒去讀快取發現快取為空，又從資料庫拉取還沒被修改的舊資料到快取，導致資料不一致 注 只有在對乙個資料在併發的進行讀寫的時候，才可能會出...
mysqldump如何保證資料一致性
作為dba的小k，搭建備機應該是家常便飯了，這時候用到的方法無非有如下三種 1 停掉一台備機 這裡叫備機1 直接拷貝整個資料目錄下的所有檔案到新的備機 這裡叫備機2 優點是簡單 快速，只需要拷貝 缺點也很明顯，在整個備份過程中備機1處於完全不可用的狀態，且備機2無法釋放備機1中因為碎片導致的空間浪費...