1.簡介
canal [kə'næl]，譯意為水道/管道/溝渠，主要用途是基於 MySQL 資料庫增量日誌解析，提供增量資料 訂閱 和 消費。應該是阿里雲DTS（Data Transfer Service）的開源版本。
2.提供的能力
Canal與DTS提供的功能基本相似：
1）基於Mysql的Slave協議實時dump binlog流，解析為事件傳送給訂閱方。
2）單Canal instance，單DTS資料訂閱通道均只支援訂閱一個RDS，提供給一個消費者。
3）可以使用canal-client客戶端進行訊息消費。
4）也可以通過簡單配置，也可以不需要自行使用canal-client消費，可以選擇直接投遞到kafka或者RocketMQ叢集，使用者只需要使用訊息佇列的consumer消費即可。
5）成功消費訊息後需要進行Ack，以確保一致性，服務端則會維護客戶端目前的消費位點。
3.工作原理
MySQL的主從複製分成三步：
- master將改變記錄到二進位制日誌(binary log)中（這些記錄叫做二進位制日誌事件，binary log events，可以通過show binlog events進行檢視）；
- slave將master的binary log events拷貝到它的中繼日誌(relay log)；
- slave重做中繼日誌中的事件，將改變反映它自己的資料。
canal 就是模擬了這個過程。
- canal模擬 MySQL slave 的互動協議，偽裝自己為 MySQL slave ，向 MySQL master 傳送 dump 協議；
- MySQL master 收到 dump 請求，開始推送 binary log 給 slave (即 canal )；
- canal 解析 binary log 物件(原始為 byte 流)；
4. canal 架構
4.1 admin版本整體架構
canal 1.1.4開始支援admin管理，通過canal-admin為canal提供整體配置管理、節點運維等面向運維的功能，提供相對友好的WebUI操作介面，方便更多使用者快速和安全的操作，替代了過去繁瑣的配置檔案管理。
整體部署架構如下。
- 多個canal-server可以組成叢集模式，每個instance任務通過zookeeper在叢集中實現高可用
- 通過多個叢集，可以實現同步資源的物理隔離
- 可以直接抓取消費投遞MQ，可以實現生產/消費解耦、訊息堆積、訊息回溯
- 可以抓取消費投遞給canal-client，在使用者的服務中進行訊息處理，減少中間過程
4.2 canal-server架構
說明：
- server代表一個canal-server執行例項，對應於一個jvm
- instance對應於一個資料佇列，是真正的變更抓取的實體 （1個server可以對應多個instance)
Instance模組
- EventParser ：資料來源接入，模擬slave協議和master進行互動，協議解析
- EventSink ：Parser和Store連結器，進行資料過濾，加工，分發的工作
- EventStore ：資料儲存
- MetaManager：增量訂閱&消費資訊管理器
1)EventParser子模組
EventParser模組的類圖設計如下
每個EventParser都會關聯兩個內部元件：CanalLogPositionManager ， CanalHAController
- CanalLogPositionManager：記錄binlog最後一次解析成功位置資訊，主要是描述下一次canal啟動的位點
- CanalHAController：支援Mysql主備，判斷當前該連哪個mysql（基於Heartbeat實現，主庫失去心跳則連備庫）
EventParser根據HAController獲知連到哪裡，通過LogPositionManager獲知從哪個位點開始解析，之後便通過Mysql Slave協議拉取binlog進行解析，推入EventSink
2）EventSink子模組
目前只提供了一個帶有實際作用的實現：GroupEventSink
GroupEventSink用於將多個instance上的資料進行歸併，常用於分庫後的多資料來源歸併。
3）EventStore子模組
EventStore的類圖如下
官方提供的實現類是
MemoryEventStoreWIthBuffer，內部採用的是一個RingBuffer：
- Put : Sink模組進行資料儲存的最後一次寫入位置
- Get : 資料訂閱獲取的最後一次提取位置
- Ack : 資料消費成功的最後一次消費位置
這些位點資訊通過MetaManager進行管理。這也解釋了為什麼一個canal instance只能支撐一個消費者：EventStore的RingBuffer只為一個消費者維護資訊。
4.3 客戶端使用
資料格式已經在前文給出，Canal和DTS客戶端均採取：
拉取事件 -> 消費 -> 消費成功後ACK
這樣的消費模式，並支援消費不成功時進行rollback，重新消費該資料。
下面是一段簡單的客戶端呼叫例項（略去異常處理）：
// 建立CanalConnector， 連線到localhost:11111
CanalConnector connector = CanalConnectors.newSingleConnector(new InetSocketAddress(AddressUtils.getHostIp(),11111), destination, "", "");
connector.connect(); // 連線
connector.subscribe(); // 開始訂閱binlog
// 開始迴圈拉取
while (running) {
Message message = connector.getWithoutAck(1024); // 獲取指定數量的資料
long batchId = message.getId();
for (Entry entry : message.getEntries()){
// 對每條訊息進行處理
}
connector.ack(batchId); // ack
}5.總結分析
5.1 優點
1）效能優異、功能全面
- canal 1.1.x 版本（release_note）,效能與功能層面有較大的突破,重要提升包括:
- 整體效能測試&優化,提升了150%. #726
- 原生支援prometheus監控 #765
- 原生支援kafka訊息投遞 #695
- 原生支援aliyun rds的binlog訂閱 (解決自動主備切換/oss binlog離線解析) （無法拒絕它的理由！）
- 原生支援docker映象 #801
2）運維方便
- canal 1.1.4版本，迎來最重要的WebUI能力，引入canal-admin工程，支援面向WebUI的canal動態管理能力，支援配置、任務、日誌等線上白屏運維能力
- Standalone的一體化解決方案，無外部服務依賴，運維更簡單，在某種程度上也意味著更穩定。
- 開箱即用，節約開發與定製成本。
- 有良好的管理控制平臺與監控系統（如果你已經有promethus監控，可以秒接canal監控）
3）多語言支援
- canal 特別設計了 client-server 模式，互動協議使用 protobuf 3.0 , client 端可採用不同語言實現不同的消費邏輯
- canal 作為 MySQL binlog 增量獲取和解析工具，可將變更記錄投遞到 MQ 系統中，比如 Kafka/RocketMQ，可以藉助於 MQ 的多語言能力
5.2 缺點
- 單instance/訂閱通道只支援訂閱單個資料庫，並只能支援單客戶端消費。每當我們需要新增一個消費端->MySQL的訂閱：對於Canal而言，就要給MySQL接一個“Slave”，可能會對主庫有一定影響。
- 訊息的Schema很弱，所有訊息的Schema均相同，客戶端需要提前知道各個表訊息的Schema與各欄位的上下文才能正確消費。
好了，花了10分鐘應該對canal有大致瞭解了，下一期，阿丸計劃手把手教你搭建canal叢集和admin管理平臺，記得關注哦。
都看到最後了，原創不易，點個關注，點個贊吧～
知識碎片重新梳理，構建Java知識圖譜：github.com/saigu/JavaK…（歷史文章查閱非常方便）