關於redis的其他的一些面試問題已經寫過了，比如常見的快取穿透、雪崩、擊穿、熱點的問題，但是還有乙個比較麻煩的問題就是如何保證快取一致性。
對於快取和資料庫的操作，主要有以下兩種方式。
先刪除快取，資料庫還沒有更新成功，此時如果讀取快取，快取不存在，去資料庫中讀取到的是舊值，快取不一致發生。
延時雙刪的方案的思路是，為了避免更新資料庫的時候，其他執行緒從快取中讀取不到資料，就在更新完資料庫之後，再sleep一段時間，然後再次刪除快取。
sleep的時間要對業務讀寫快取的時間做出評估，sleep時間大於讀寫快取的時間即可。
執行緒1刪除快取，然後去更新資料庫
執行緒2來讀快取，發現快取已經被刪除，所以直接從資料庫中讀取，這時候由於執行緒1還沒有更新完成，所以讀到的是舊值，然後把舊值寫入快取
執行緒1，根據估算的時間，sleep，由於sleep的時間大於執行緒2讀資料+寫快取的時間，所以快取被再次刪除
如果還有其他執行緒來讀取快取的話，就會再次從資料庫中讀取到最新值
如果反過來操作，先更新資料庫，再刪除快取呢？
這個就更明顯的問題了，更新資料庫成功，如果刪除快取失敗或者還沒有來得及刪除，那麼，其他執行緒從快取中讀取到的就是舊值，還是會發生不一致。
先更新資料庫，成功後往訊息佇列發訊息，消費到訊息後再刪除快取，借助訊息佇列的重試機制來實現，達到最終一致性的效果。
引入訊息中介軟體之後，問題更複雜了，怎麼保證訊息不丟失更麻煩
就算更新資料庫和刪除快取都沒有發生問題，訊息的延遲也會帶來短暫的不一致性，不過這個延遲相對來說還是可以接受的
為了解決快取一致性的問題單獨引入乙個訊息佇列，太複雜了。
其實，一般大公司本身都會有監聽binlog訊息的訊息佇列存在，主要是為了做一些核對的工作。
這樣，我們可以借助監聽binlog的訊息佇列來做刪除快取的操作。這樣做的好處是，不用你自己引入，侵入到你的業務**中，中介軟體幫你做了解耦，同時，中介軟體的這個東西本身就保證了高可用。
當然，這樣訊息延遲的問題依然存在，但是相比單純引入訊息佇列的做法更好一點。
而且，如果併發不是特別高的話，這種做法的實時性和一致性都還算可以接受的。
每次放入快取的時候，設定乙個過期時間，比如5分鐘，以後的操作只修改資料庫，不操作快取，等待快取超時後從資料庫重新讀取。
如果對於一致性要求不是很高的情況，可以採用這種方案。
這個方案還會有另外乙個問題，就是如果資料更新的特別頻繁，不一致性的問題就很大了。
在實際生產中，我們有一些活動的快取資料是使用這種方式處理的。
因為活動並不頻繁發生改變，而且對於活動來說，短暫的不一致性並不會有什麼大的問題。
我們以先更新資料庫，再刪除快取來舉例。
如果是更新的話，那就是先更新資料庫，再更新快取。
舉個例子：如果資料庫1小時內更新了1000次，那麼快取也要更新1000次，但是這個快取可能在1小時內只被讀取了1次，那麼這1000次的更新有必要嗎？
反過來，如果是刪除的話，就算資料庫更新了1000次，那麼也只是做了1次快取刪除，只有當快取真正被讀取的時候才去資料庫載入。
首先，我們要明確一點，快取不是更新，而應該是刪除。
先刪除快取，再更新資料庫。解決方案是使用延遲雙刪。
針對快取一致性要求不是很高的場景，那麼只通過設定超時時間就可以了。
其實，如果不是很高的併發，無論你選擇先刪快取還是後刪快取的方式，都幾乎很少能產生這種問題，但是在高併發下，你應該知道怎麼解決問題。
快取一致性問題怎麼解決
關於 redis 的其他的一些面試問題已經寫過了，比如常見的快取穿透 雪崩 擊穿 熱點的問題，但是還有乙個比較麻煩的問題就是如何保證快取一致性。對於快取和資料庫的操作，主要有以下兩種方式。先刪除快取，資料庫還沒有更新成功，此時如果讀取快取，快取不存在，去資料庫中讀取到的是舊值，快取不一致發生。延時雙...
快取一致性問題討論
在資料庫與快取之間的一致性問題?最好的是 先寫資料庫,再刪除快取.原因 寫資料庫之後證明寫成功了,順便把快取刪除了.寫成功之後拿到的資料就是最新的.寫資料庫失敗了,快取沒刪除,還是原來的資料,無傷大雅,寫失敗了,刪除快取成功了?這種事情不會發生的,即使發生了,也沒有問題,查庫,還是原來的資料.問題來...
redis快取一致性問題
1 不一致產生的原因？我們在是使用redis過程中，通常會這樣做，先讀取快取，如果快取不存在，則讀取資料庫。不管是先寫庫，再刪除快取 還是先刪除快取，再寫庫，都有可能出現資料不一致的情況。因為寫和讀是併發的，沒法保證順序，如果刪除了快取，還沒有來得及寫庫，另乙個執行緒就來讀取，發現快取為空，則去資料...