基于MySql BinLog的增量訂閱和消費組件：Canal

• Cancal是阿里13年1月開源的一個基于MySql數據庫Binlog實現的增量訂閱和消費的組件。項目取名Canal取自管道的英文單詞，流轉的醫生，是一個定位于基于MySql數據庫Binlog增量日志來實現數據庫鏡像，試試備份和怎梁書記消費的通用組件。
• 早期的數據庫同步業務，大多使用MySql數據庫的觸發器機制（Trigger）來獲取數據庫的增量變更，之后逐步闡釋基于數據庫日志解析來獲取數據，再次激起上實現數據同步，由此衍生出了數據庫增量訂閱和消費業務----Canal項目。

Canal核心思想

• Canal工作原理比較簡單，核心思想就是模擬MySql Slave的交互協議，將字節偽裝稱為一個MySql的Slave激起，不斷向Master發送Dump請求。Master收到Dump后，開始推送對應Binary Log給這個Slave（其實是Canal）。Canal收到Binary log，解析出對應的Binary Log對象后就可以進行二次消費了，基本工作如下：
  

Canal Server主備切換設計

• 在Canal的設計中，基于對容災的設計，會配置兩個或者更多的Canal Server負責一個MySql數據庫實例的數據增量復制，另外一個方面，為減少CanalServer的Dump請求對MySql Master帶來的影響，要求不同Canal Server上的Instance在同一個時刻只能有一個處于Running狀態，其他的instance都處于Standby狀態，這就使得Canal必須具備主從切換能力，此部分功能利用Zookeeper來完成，如下圖：
  
• 嘗試啟動： 每個Canal Server在啟動某個Canal instance的時候，都會首先向Zookeeper進行一次闡釋啟動判斷，都想Zookeeper創建同一個臨時節點，那個Canal Server創建成功，就讓哪一個啟動。以“example”這個instance為例，都創建“/otter/canal/destinations/example/running”節點，Zookeeper保證只有一個成功
• 啟動instance： 假設最終IP：10.1.12.211的Canal Server成功創建，會將字節機器信息寫入節點中，并同時啟動instance，其他CanServer會將字節狀態設置Standby同時對成功節點注冊Watch監聽，以監聽節點變化情況。成功節點注冊數據如下：

{"active":true,"address":"10.1.12.211:11111","cid":1}

• 主備切換：CanalServer在運行過程中，發送異常，因為創建的是Zookeeper的臨時節點，當Running狀態的CanalServer掛點或者網絡原因斷開，那么“/otter/canal/destinations/example/running”節點就會在一段時間后消失。其他Standby狀態的CanalServer已經添加過Watch，因此會接受到Zookeeper發來的通知，重復1 步驟以此實現主備切換

• 特殊設計：Canal設計中，當有那種服務器網絡閃斷的假死清，導致Zookeeper任務其會話失效，此時其實CanalServer對應JVM并沒有退出，狀態正常，CanalServer做了一個策略：

  • 狀態為Standby的CanalServer收到Running節點釋放的通知后，會延遲一段時間搶占Running節點，而原來的Running狀態的instance不需要等待直接獲取Running節點。這樣就盡可能保證瞬時假死情況下不需要切換避免了五位的資源釋放和重新分配，目前延遲時間是5秒，即Running節點針對假死狀態的保護器為5秒

Canal Server的HA設計

• Canal Servers進行數據消費錢，需要找到Master的CanalServer節點，在上文中已經講了，針對每一個數據復制實例，例如example，都會在“/otter/canal/destinations/example/running” 節點記錄正在運行的CanalServer，所有CanalServer鏈接Zookeeper后讀取這個節點信息即可

從Zookeeper中讀取當前處于Running狀態的server：CanalClient啟動會首先從“/otter/canal/destinations/example/running” 節點讀取當前Running狀態的Server，同時客戶端也會將字節的信息注冊到Zookeeper的“/otter/canal/destinations/example/1001/running” 下面,其中1001目錄層級是代表客戶端唯一標識節點內容如下：

{"active":true,"address":"10.1.12.211:50544","clientId":1001}

注冊Running節點數據變化的監聽： 由于CanalServer有掛掉的風險，CanalClient還會對“/otter/canal/destinations/example/running”節點注冊一個監聽，一旦server主備切換，Client隨時能感知到。

鏈接對應RunningServer進行數據消費。

數據消費點位記錄

• 由于存在CanalClient重啟或者其他變化，為避免數據消費順序錯亂，Canal必須對數據消費點位進行實時的記錄，也就是記錄下本次讀取到的Binlog日志到第幾行了，數據消費后，CanalServer會在Zookeeper上記錄當前最后一次消費成功的Binarylog點位，一旦發生Client重啟，只需從這個點位后一個點位開始消費，具體做法如下：
• 在Zookeeper的“/otter/canal/destinations/example/1001/cursor”節點中記錄下客戶端消費的詳細點位信息：
  
• 具體內容如下：

{"@type":"com.alibaba.otter.canal.protocol.position.LogPosition","identity":{"slaveId":-1,"sourceAddress":{"address":"10.21.16.8","port":3306}},"postion":{"gtid":"","included":false,"journalName":"mysql-bin.004073","position":82751773,"serverId":109065,"timestamp":1589508966000}}

上一篇Zookeeper–Watcher機制源碼剖析二
下一篇Zookeeper實踐與應用-- Nginx負載均衡差異

總結

以上是生活随笔為你收集整理的Zookeeper实践与应用- Canal的全部內容，希望文章能夠幫你解決所遇到的問題。

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