關於 Redis 的其他的一些面試問題已經寫過了，比如常見的快取穿透、雪崩、擊穿、熱點的問題，但是還有一個比較麻煩的問題就是如何保證快取一致性。

對於快取和資料庫的操作，主要有以下兩種方式。

先刪快取，再更新資料庫解決方案延時雙刪

Sleep 的時間要對業務讀寫快取的時間做出評估，Sleep 時間大於讀寫快取的時間即可。

流程如下：

執行緒1刪除快取，然後去更新資料庫。執行緒2來讀快取，發現快取已經被刪除，所以直接從資料庫中讀取，這時候由於執行緒1還沒有更新完成，所以讀到的是舊值，然後把舊值寫入快取。執行緒1，根據估算的時間，Sleep，由於 Sleep 的時間大於執行緒2讀資料+寫快取的時間，所以快取被再次刪除。如果還有其他執行緒來讀取快取的話，就會再次從資料庫中讀取到最新值。解決方案訊息佇列

這是網上很多文章裡都有寫過的方案。但是這個方案的缺陷會更明顯一點。

這個解決方案其實問題更多。

進階版訊息佇列

為了解決快取一致性的問題單獨引入一個訊息佇列，太複雜了。

其實，一般大公司本身都會有監聽 binlog 訊息的訊息佇列存在，主要是為了做一些核對的工作。

當然，這樣訊息延遲的問題依然存在，但是相比單純引入訊息佇列的做法更好一點。

而且，如果併發不是特別高的話，這種做法的實時性和一致性都還算可以接受的。

其他解決方案設定快取過期時間

每次放入快取的時候，設定一個過期時間，比如5分鐘，以後的操作只修改資料庫，不操作快取，等待快取超時後從資料庫重新讀取。

如果對於一致性要求不是很高的情況，可以採用這種方案。

這個方案還會有另外一個問題，就是如果資料更新的特別頻繁，不一致性的問題就很大了。

在實際生產中，我們有一些活動的快取資料是使用這種方式處理的。

因為活動並不頻繁發生改變，而且對於活動來說，短暫的不一致性並不會有什麼大的問題。

如果是更新的話，那就是先更新資料庫，再更新快取。

舉個例子：如果資料庫 1 小時內更新了 1000 次，那麼快取也要更新 1000 次，但是這個快取可能在1小時內只被讀取了 1 次，那麼這 1000 次的更新有必要嗎？

總結

針對快取一致性要求不是很高的場景，那麼只通過設定超時時間就可以了。

其實，如果不是很高的併發，無論你選擇先刪快取還是後刪快取的方式，都幾乎很少能產生這種問題，但是在高併發下，你應該知道怎麼解決問題。