共計 1409 個字符，預計需要花費 4 分鐘才能閱讀完成。

這篇文章給大家介紹如何保持 MySQL 和 Redis 中的數據一致，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

在高并發的業務場景下，MySQL 和 Redis 的數據一致性就顯得很重要了，多次訪問 MySQL 就會導致奔潰或者延緩速度，而緩存 Redis 過多也會出問題，那就是丟數據，存著存著，數據就丟了

Redis  在互聯網行業中使用最為廣泛。在很多時候也被稱為“內存數據庫”，它集合了緩存和數據庫的優勢，但并非開啟持久化和主備同步機制就可以高枕無憂。

寫入數據庫成功，即讓緩存失效，下一次讀取時再緩存。這是緩存的實時策略。

從架構設計的角度思考：緩存就是緩存，緩存數據會隨時丟失，緩存存在的目的是攔截到數據庫的請求，相比數據的可靠性、一致性，還是吞吐量、穩定性優先。

在考慮數據一致性的問題上由三種刷新策略

實時策略

異步策略

定時策略

實時策略是最常用的策略，能夠讓用戶有最好的體驗，但是一旦數據量過大就會出現，數據苦往往會受不了

異步策略適用于，數據量大，但是數據并不重要，因為可能會導致臟數據或者數據丟失

定時策略適用于，數據量大，數據也很重要的情況下，這也是最穩定的方案

讀取的過程，應用程序先從  cache  取數據，沒有得到，則從數據庫中取數據，成功后，放到緩存中。如果命中，應用程序從  cache  中取數據，取到后返回。

寫入的過程，把數據存到數據庫中，成功后，再刪除緩存，刪除后下次讀取的時候，會被寫入緩存。

從用戶體驗的角度，應該數據庫有了寫入，就馬上廢棄緩存，觸發一次數據庫的讀取，從而更新緩存。

然而，這和高并發就矛盾了——如果所有的都實時從數據庫里面讀取，高并發場景下，數據庫往往受不了。

在讀取寫入數據時，適用定時策略一般不會出問題

MySQL 持久化數據，Redis 只讀數據

MySQL 和 Redis 處理不同的數據類型
MySQL 處理實時性數據，Redis 處理對實時性要求并不是很高的數據。在并發不高的情況下，讀取操作優先讀取 redis，不存在的話再去訪問 MySQL，并把讀取到的數據寫回 Redis 中；寫入操作直接寫 MySQL，然后后再寫入 Redis。在并發高的情況下，讀取操作和上面一樣，寫入操作則使用異步寫入，先寫入 Redis 后直接返回，然后定時定期的寫入 MySQL

而一旦涉及到更新數據，就容易出現緩存和數據庫之間的數據一致性的問題，不管是先寫入數據庫再刪除緩存，還是先刪除緩存再寫入數據庫，都有可能出現數據不一致的情況，例如：

先寫入數據庫，再刪除緩存前，線程宕機了，沒有刪除掉緩存，就會出現數據不一致的情況

先刪除 Redis，還沒來得及寫入數據庫，另外一個線程就來讀取，發現緩存為空，這個時候就會跑去數據庫讀取數據寫入緩存，這個時候緩存中的數據就是臟數據

因為寫入和讀取是并發的，沒有辦法保證順序，就會出現緩存和數據庫的數據是不一致的問題，這時候就可以使用

延時雙刪策略

在寫庫前后都進行 Redis.del(key) 操作，并且設定合理地超時時間

先刪緩存

再寫數據庫

休眠一段時間

再刪緩存

設置緩存的過期時間

理論上來講，設置緩存過期時間，是保證最終一致性的解決方案。所有的寫入操作以數據庫為準，只要到達緩存過期時間，則后面的讀請求自然會從數據庫中讀取新值然后回填緩存

關于如何保持 MySQL 和 Redis 中的數據一致就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。