redis快取一致性問題解決方案

使用快取來儲存熱點資料是應對高併發的常用手段之一，通過使用快取，大大減輕了資料庫的壓力，同時減少了響應請求的時間。

但是引入快取之後，隨之而來的問題就是當db資料更新時，快取中的資料就會與db資料不一致，這時候就需要對快取的資料進行更新或者淘汰快取，這篇文章就是分析各種處理快取一致性問題的解決方案。

更新db和操作快取兩個動作之間，明顯缺乏原子性，有可能更新db完成，但是操作（淘汰或者更新）快取失敗，反之亦然。所以兩者之間必然是由斷層的，那麼先選擇操作誰才是最佳的方案？

這裡推薦先更新db，然後再更新或者淘汰快取，原因如下

兩個動作之間原則上是非原子性的，乙個是更新db，乙個是更新redis。但是，通常我們使用乙個妥協的方案，類似於分布式事務最終一致性的實現，這裡也可以使用訊息佇列實現最終一致性的訊息保證。

嚴格上來說，不論是更新快取，還是淘汰快取，都是可能出現快取不一致的，但是從分析上來說，更新快取的方式出現快取不一致的可能性更大，如果是業務上對快取不一致容忍性比較大，那麼選擇更新還是淘汰都是可以的，下面來分析一下，兩個綜合的方案可能出現的問題。

所以，如果要使用更新快取的方式來保證快取與db資料一致性，需要考慮以上三個問題。

通過上面的分析，可以知道更新db在更新快取的實現方案，可能面臨更多的問題需要考慮，對比之下，也許是方案二比較好。在實際生產中，兩個方案都可能出現db與快取資料不一致，如果對資料不一致容忍度比較低，那麼建議是採用先更新db，後淘汰快取方案。

這裡只是簡單方案分析，如果複雜點的場景，還需要考慮db讀寫分離時，主從資料同步延時導致的快取不一致。