關於Redis的其他的一些面試問題已經寫過了，比如常見的緩存穿透、雪崩、擊穿、熱點的問題，但是還有一個比較麻煩的問題就是如何保證緩存一致性。
對於緩存和數據庫的操作，主要有以下兩種方式。
先刪緩存，再更新數據庫
先刪除緩存，數據庫還沒有更新成功，此時如果讀取緩存，緩存不存在，去數據庫中讀取到的是舊值，緩存不一致發生。
解決方案
延時雙刪
延時雙刪的方案的思路是，爲了避免更新數據庫的時候，其他線程從緩存中讀取不到數據，就在更新完數據庫之後，再sleep一段時間，然後再次刪除緩存。
sleep的時間要對業務讀寫緩存的時間做出評估，sleep時間大於讀寫緩存的時間即可。
流程如下：
線程1刪除緩存，然後去更新數據庫
線程2來讀緩存，發現緩存已經被刪除，所以直接從數據庫中讀取，這時候由於線程1還沒有更新完成，所以讀到的是舊值，然後把舊值寫入緩存
線程1，根據估算的時間，sleep，由於sleep的時間大於線程2讀數據+寫緩存的時間，所以緩存被再次刪除
如果還有其他線程來讀取緩存的話，就會再次從數據庫中讀取到最新值
先更新數據庫，再刪除緩存
如果反過來操作，先更新數據庫，再刪除緩存呢？
這個就更明顯的問題了，更新數據庫成功，如果刪除緩存失敗或者還沒有來得及刪除，那麼，其他線程從緩存中讀取到的就是舊值，還是會發生不一致。
解決方案
消息隊列
這是網上很多文章裏都有寫過的方案。但是這個方案的缺陷會更明顯一點。
先更新數據庫，成功後往消息隊列發消息，消費到消息後再刪除緩存，藉助消息隊列的重試機制來實現，達到最終一致性的效果。
這個解決方案其實問題更多。
引入消息中間件之後，問題更復雜了，怎麼保證消息不丟失更麻煩
就算更新數據庫和刪除緩存都沒有發生問題，消息的延遲也會帶來短暫的不一致性，不過這個延遲相對來說還是可以接受的
進階版消息隊列
爲了解決緩存一致性的問題單獨引入一個消息隊列，太複雜了。
其實，一般大公司本身都會有監聽binlog消息的消息隊列存在，主要是爲了做一些覈對的工作。
這樣，我們可以藉助監聽binlog的消息隊列來做刪除緩存的操作。這樣做的好處是，不用你自己引入，侵入到你的業務代碼中，中間件幫你做了解耦，同時，中間件的這個東西本身就保證了高可用。
當然，這樣消息延遲的問題依然存在，但是相比單純引入消息隊列的做法更好一點。
而且，如果併發不是特別高的話，這種做法的實時性和一致性都還算可以接受的。
其他解決方案
設置緩存過期時間
每次放入緩存的時候，設置一個過期時間，比如5分鐘，以後的操作只修改數據庫，不操作緩存，等待緩存超時後從數據庫重新讀取。
如果對於一致性要求不是很高的情況，可以採用這種方案。
這個方案還會有另外一個問題，就是如果數據更新的特別頻繁，不一致性的問題就很大了。
在實際生產中，我們有一些活動的緩存數據是使用這種方式處理的。
因爲活動並不頻繁發生改變，而且對於活動來說，短暫的不一致性並不會有什麼大的問題。
爲什麼是刪除，而不是更新緩存？
我們以先更新數據庫，再刪除緩存來舉例。
如果是更新的話，那就是先更新數據庫，再更新緩存。
舉個例子：如果數據庫1小時內更新了1000次，那麼緩存也要更新1000次，但是這個緩存可能在1小時內只被讀取了1次，那麼這1000次的更新有必要嗎？
反過來，如果是刪除的話，就算數據庫更新了1000次，那麼也只是做了1次緩存刪除，只有當緩存真正被讀取的時候纔去數據庫加載。
總結
首先，我們要明確一點，緩存不是更新，而應該是刪除。
刪除緩存有兩種方式：
先刪除緩存，再更新數據庫。解決方案是使用延遲雙刪。
先更新數據庫，再刪除緩存。解決方案是消息隊列或者其他binlog同步，引入消息隊列會帶來更多的問題，並不推薦直接使用。
針對緩存一致性要求不是很高的場景，那麼只通過設置超時時間就可以了。
其實，如果不是很高的併發，無論你選擇先刪緩存還是後刪緩存的方式，都幾乎很少能產生這種問題，但是在高併發下，你應該知道怎麼解決問題。
—————END—————
喜歡本文的朋友，歡迎關注公衆號 程序員小灰，收看更多精彩內容
點個[在看]，是對小灰最大的支持！