本篇內容主要講解“實現Redis緩存和數據庫的數據一致性的方法”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“實現Redis緩存和數據庫的數據一致性的方法”吧!
一、一致性
1、強一致性
2、弱一致性
3、最終一致性
二、redis緩存和mysql數據庫數據一致性解決
1、方案一：采用延時雙刪策略
2、方案二：一步更新緩存（基于訂閱Binlog的同步機制）
首先，我們先來看看有哪幾種一致性的情況呢？
如果你的項目對緩存的要求是強一致性的，那么請不要使用緩存。這種一致性級別是最符合用戶直覺的，它要求系統寫入什么，讀出來的也會是什么，用戶體驗好，但實現起來往往對系統的性能影響大。
這種一致性級別約束了系統在寫入成功后，不承諾立即可以讀到寫入的值，也不承諾多久之后數據能夠達到一致，但會盡可能地保證到某個時間級別（比如秒級別）后，數據能夠達到一致狀態。
3、最終一致性
最終一致性是弱一致性的一個特例，系統會保證在一定時間內，能夠達到一個數據一致的狀態。這里之所以將最終一致性單獨提出來，是因為它是弱一致性中非常推崇的一種一致性模型，也是業界在大型分布式系統的數據一致性上比較推崇的模型。一般情況下，高可用只確保最終一致性，不確保強一致性。
強一致性，讀請求和寫請求會串行化，串到一個內存隊列里去，這樣會大大增加系統的處理效率，吞吐量也會大大降低。
這張圖，大多數人的很多業務操作都是根據這個圖來做緩存的。但是一旦設計到雙寫或者
數據庫和緩存更新等操作，就很容易出現數據一致性的問題。無論是先寫數據庫，在刪除緩存，還是先刪除緩存，在寫入數據庫，都會出現數據一致性的問題。列舉兩個小例子。
1、 先刪除了redis緩存，但是因為其他什么原因還沒來得及寫入數據庫，另外一個線程就來讀取，發現緩存為空，則去數據庫讀取到之前的數據并寫入緩存，此時緩存中為臟數據。
2、 如果先寫入了數據庫，但是在緩存被刪除前，寫入數據庫的線程因為其他原因被中斷了，沒有刪除掉緩存，就也會出現數據不一致的情況。
總的來說，寫和讀在多數情況下都是并發的，不能絕對保證先后順序，就會很容易出現緩存和數據庫數據不一致的情況，還怎么解決呢？
基本思路： 在寫庫前后都進行刪除緩存操作，并且設置合理的超時時間
基本步驟： 先刪除緩存–再寫數據庫—休眠一段時間—再次刪除緩存
注：休眠的時間是根據自己的項目的讀數據業務邏輯的耗時來確定的。這樣做主要是為了保證在寫請求之前確保讀請求結束，寫請求可以刪除讀請求造成的緩存臟數據。
該方案的弊端： 集合雙刪策略+緩存超時策略設置，這樣最差的結果就是在超時時間內數據存在不一致，又增加了寫請求的耗時。
基本思路： mysql Binlog增強訂閱消費+消息隊列+增量數據更新到redis—讀redis：熱數據基本上都在redis—寫mysql：增刪改都是操作mysql—更新redis數據：mysql的數據操作Binlog，來更新redis
我們再來看看詳細的過程
1）、數據操作主要分為兩大塊：
一個是全量，將全部數據寫去redis；另一個就是增量（update、insert、delete），實時更新。
2）、讀取binlog后分析 ，利用消息隊列,推送更新各臺的redis緩存數據。
這樣一旦MySQL中產生了新的寫入、更新、刪除等操作，就可以把binlog相關的消息推送至Redis，Redis再根據binlog中的記錄，對Redis進行更新。
其實這種機制，很類似MySQL的主從備份機制，因為MySQL的主備也是通過binlog來實現的數據一致性。
這里可以結合使用canal(阿里的一款開源框架)，通過該框架可以對MySQL的binlog進行訂閱，而canal正是模仿了mysql的slave數據庫的備份請求，使得Redis的數據更新達到了相同的效果。
當然，這里的消息推送工具你也可以采用別的第三方：kafka、rabbitMQ等來實現推送更新Redis。
到此，相信大家對“實現Redis緩存和數據庫的數據一致性的方法”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
