問題出現原因

• 并發時候無法保證讀寫的先后順序，如果刪掉了緩存還沒來得及寫庫，另外一個縣城就多來讀取，發現緩存為空就去讀取數據庫并且寫入緩存，這時候緩存中就是臟數據
• 如果先寫庫，在刪除緩存前，寫庫的線程宕機，沒有刪除掉緩存，則也會出現不一致的情況
• 如果redis集群，在注冊模式中，寫主庫，讀從庫，也會出現redis復制存在的一些延遲操作，也可能導致數據不一致

解決方案

雙刪除+超時

• 寫庫前后都加上redis.del(key)操作，并且舍得合了的超時時間，這樣最差的情況就是在超時時間之內存在不太一致，當然這種情況極其少見，可能的原因就是服務器宕機，此種情況可以滿足絕大多數需求
• 這種策略要考慮redis的和數據庫注冊同步的耗時，所以第二次刪除前最好先等待一段時間，等待同步完成，然后在刪除，這樣缺點也會增加線程占用時間。

通過讀取binlog的方式，異步淘汰緩存

• 好處在于業務上的侵入性低，將緩存和數據庫的不一致時間盡量縮小。
• binlog介紹：mysql的binlog日志作用在于記錄mysql內部的增刪改查等對mysql有更新操作的內容的記錄，對數據的select已經show不會被binlog記錄，主要用于數據庫的主從復制，以及增量恢復。
• binlog日志模式：
  • STATEMENT模式（SBR）：每條修改數據庫的sql都會記錄到binlog中，有點事并不需要記錄每條sql和每一行數據的變化，有點在于減少binlog日志，缺點是某些情況下master-slave數據不一致比如，sleep()函數，last_insert_id()
  • ROW模式（RBR）：不記錄每條sql的上下文信息，僅需要記錄那條數據被修改了，修改成什么樣，不會出現某些特定的情況下的存儲過程或者function或者targger的調用和出發無法被復制的問題，但是會產生大量的日志
  • MIXED模式(MBR)以上兩種模式的混合使用，一般復制使用STATEMENT模式保持binlog，對于STATEMENT模式無法復制的操作使用ROW模式保存binlog，mysql會根據執行的sql語句選擇日志保持方式

mysql的UDF

• 這種方法思路是通過數據庫中的Targger調用自定義的函數庫來觸發對redis的操作，但是這個有一定學習成本，需要基于mysql的APi進行開發使用的C++語言，阿里早期的解決方案

binlog具體實施方案

• 通過使用open-replicator解析binlog
• 使用canal進行同步—阿里框架

canal介紹(http://www.cnblogs.com/duanxz/p/5062833.html)

• mysql主從負責工作原理

• 負責分為三步

master將改變記錄到二進制日志binary log 中， 可以通過mysql命令 show binlog events查看

slave將master的binary log events 拷貝到他的中繼日志，用來中轉數據

slave重做中繼日志中的事件，將改變反映他自己的數據

• canal工作原理

canal是模式mysql slave的交互協議，偽裝ziji shi mysql slave,向master發送dump協議

mysql master 收到dump請求，開始推送binary log給slave（這里的slave就是canal）

canal解析binary log對象

canal官網

• quickStart：https://github.com/alibabatech/canal/wiki/QuickStart
• 項目代碼：https://github.com/alibabatech/canal
• 阿里升級版本otter：https://github.com/alibaba/otter

總結

以上是生活随笔為你收集整理的Redis和DB数据一致性解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。