上一文中提到延時雙刪等策略實現數據一致性的時候，可能存在刪除緩存失敗的情況，就會出現緩存和數據庫不一致的問題。為了應對刪除緩存失敗而導致數據不一致的問題，可以通過回溯數據庫日志文件，提供一個保障的重試機制即可。

流程如下圖所示：

(1)更新數據庫數據

(2)數據庫會將操作信息寫入binlog日志當中

(3)訂閱程序提取出所需要的數據以及key

(4)另起一段非業務代碼，獲得該信息

(5)嘗試刪除緩存操作，發現刪除失敗

(6)將這些信息發送至消息隊列

(7)重新從消息隊列中獲得該數據，重試操作。

可以借鑒阿里的方法：使用中間件canal

Canal是什么

canal 是阿里巴巴的一個開源項目，基于java實現，已經在很多大型的互聯網項目生產環境中使用，包括阿里、美團等都有廣泛的應用，是一個非常成熟的數據庫同步方案，基礎的使用只需要進行簡單的配置即可。canal是通過偽裝成mysql 的從庫，監聽mysql 的binlog日志來獲取數據。binlog設置為row模式以后，不僅能獲取到執行的每一個增刪改的腳本，同時還能獲取到修改前和修改后的數據，基于這個特性，canal就能高性能的獲取到mysql數據數據的變更。

Canal用途：

• 數據庫鏡像

• 數據庫實時備份

• 索引構建和實時維護(拆分異構索引、倒排索引等)

• 業務 cache 緩存刷新

• 帶業務邏輯的增量數據處理

在理解canal的原理前，我們先來看看關于MySQL數據庫主從數據庫的基礎知識，這樣就能更高效的理解Canal。

數據庫的讀寫分離

為了應對高并發場景，MySQL支持把一臺數據庫主機分為單獨的一臺寫主庫(主要負責寫操作)，而把讀的數據庫壓力分配給讀的從庫，而且讀從庫可以變為多臺，這就是讀寫分離的典型場景。

數據庫主從同步

實現數據庫的讀寫分離，是通過數據庫主從同步，讓從數據庫監聽主數據庫Binlog實現的。大體流程如下：

?

MySQL master 將數據變更寫入二進制日志( binary log, 可以通過 show binlog events 進行查看)

MySQL slave 將 master 的 binary log events 拷貝到它的中繼日志(relay log)

MySQL slave 重放 relay log 中事件，將數據變更反映它自己的數據

?

可以看到，這種架構下會有一個問題，數據庫主從同步會存在延遲，那么就會有短暫的時間，主從數據庫的數據是不一致的。

這種不一致大多數情況下非常短暫，很多時候我們可以忽略他。

但一旦要求數據一致，就會引申出如何解決這個問題的思考。

數據庫主從同步一致性問題

我們通常使用MySQL主從復制來解決MySQL的單點故障問題，其通過邏輯復制的方式把主庫的變更同步到從庫，主從之間無法保證嚴格一致的模式，

于是，MySQL的主從復制帶來了主從“數據一致性”的問題。MySQL的復制分為：異步復制、半同步復制、全同步復制。

---

異步復制

MySQL默認的復制即是異步復制，主庫在執行完客戶端提交的事務后會立即將結果返給給客戶端，并不關心從庫是否已經接收并處理，這樣就會有一個問題，主如果crash掉了，此時主上已經提交的事務可能并沒有傳到從庫上，如果此時，強行將從提升為主，可能導致新主上的數據不完整。

?

主庫將事務 Binlog 事件寫入到 Binlog 文件中，此時主庫只會通知一下 Dump 線程發送這些新的 Binlog，然后主庫就會繼續處理提交操作，而此時不會保證這些 Binlog 傳到任何一個從庫節點上。

?

---

全同步復制

指當主庫執行完一個事務，所有的從庫都執行了該事務才返回給客戶端。因為需要等待所有從庫執行完該事務才能返回，所以全同步復制的性能必然會收到嚴重的影響。

?

當主庫提交事務之后，所有的從庫節點必須收到、APPLY并且提交這些事務，然后主庫線程才能繼續做后續操作。但缺點是，主庫完成一個事務的時間會被拉長，性能降低。

?

---

半同步復制

是介于全同步復制與全異步復制之間的一種，主庫只需要等待至少一個從庫節點收到并且 Flush Binlog 到 Relay Log 文件即可，主庫不需要等待所有從庫給主庫反饋。同時，這里只是一個收到的反饋，而不是已經完全完成并且提交的反饋，如此，節省了很多時間。

?

介于異步復制和全同步復制之間，主庫在執行完客戶端提交的事務后不是立刻返回給客戶端，而是等待至少一個從庫接收到并寫到relay log中才返回給客戶端。相對于異步復制，半同步復制提高了數據的安全性，同時它也造成了一定程度的延遲，這個延遲最少是一個TCP/IP往返的時間。所以，半同步復制最好在低延時的網絡中使用。

?

事實上，半同步復制并不是嚴格意義上的半同步復制，MySQL半同步復制架構中，主庫在等待備庫ack時候，如果超時會退化為異步后，也可能導致“數據不一致”。

?

當半同步復制發生超時時(由rpl_semi_sync_master_timeout參數控制，單位是毫秒，默認為10000，即10s)，會暫時關閉半同步復制，轉而使用異步復制。當master dump線程發送完一個事務的所有事件之后，如果在rpl_semi_sync_master_timeout內，收到了從庫的響應，則主從又重新恢復為半同步復制。

?

Canal工作原理

了解了數據庫從庫的數據同步原理，理解canal便十分簡單，其工作原理為:

• canal 模擬 MySQL slave 的交互協議，偽裝自己為 MySQL slave ，向 MySQL master 發送dump 協議

• MySQL master 收到 dump 請求，開始推送 binary log 給 slave (即 canal )

• canal 解析 binary log 對象(原始為 byte 流)

總結來說，canal將自己偽裝成mysql的從庫，從主庫那里消費并解析binlog，通過日志來保持數據的一致性。

Canal實戰

因為篇幅有限，對canal的實際使用感興趣的同學可以在我的個人博客查看：

https://blog.csdn.net/big_white_py/article/details/107826180

總結

以上是生活随笔為你收集整理的canal mysql从库_canal中间件|数据增量同步解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

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