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 架構
canal 1.1.4開始支援admin管理，通過canal-admin為canal提供整體配置管理、節點運維等面向運維的功能，提供相對友好的webui操作界面，友善更多使用者快速和安全的操作，替代了過去繁瑣的配置檔案管理。
整體部署架構如下。
多個canal-server可以組成叢集模式，每個instance任務通過zookeeper在叢集中實作高可用
通過多個叢集，可以實作同步資源的實體隔離
可以直接抓取消費投遞mq，可以實作生産/消費解耦、消息堆積、消息回溯
可以抓取消費投遞給canal-client，在使用者的服務中進行消息處理，減少中間過程
說明：
每個叢集可以由多個server組成；
每個server代表一個canal-server運作執行個體jvm；
每個server上可以運作一個或多個instance;
每個instance對應于一個資料隊列，是真正的變更抓取的實體
1）instance子產品
eventparser ：資料源接入，模拟mysql slave協定從master上dump binlog，并進行解析
eventsink ：對dump的資料進行過濾、加工、分發，連接配接parser和store
eventstore ：對sink子產品處理後的資料進行臨時存儲
metamanager：中繼資料管理器
主要有兩個核心元件組成：
canallogpositionmanager：用來記錄最新解析成功的binlog position資訊，在canal重新開機後，作為起始位點
canalhacontroller：支援mysql主備，基于heartbeat判斷目前資料庫連接配接的有效性，一旦主庫失去心跳，就切換連接配接備庫
eventparser從canalhacontroller确定連接配接mysql的位置，然後通過logpositionmanager确定binlog解析位點的起點，最後便通過dump協定拉取binlog進行解析,把解析後的消息存入eventsink
目前隻有一個實作類groupeventsink，用來把多個instance上的資料進行歸并，主要用于分庫後的多資料歸并。
目前隻實作了基于記憶體存儲的memoryeventstorewithbuffer，據說很多年前就聲稱要支援基于檔案存儲的實作，不過到現在還沒有具體的實作類。
memoryeventstorewithbuffer内部采用的是一個ringbuffer，我們可以了解為基于記憶體的高性能消息隊列。如果使用canal-client直接消費canal-server的資料，那麼隻能通過這個消息隊列做一定程度的消息堆積。
ringbuffer如下圖所示：
put : sink子產品進行資料存儲的最後一次寫入位置
get : 資料訂閱擷取的最後一次提取位置
ack : 資料消費成功的最後一次消費位置
這些位點資訊通過metamanager進行管理。這也解釋了為什麼一個canal instance隻能支撐一個消費者：eventstore的ringbuffer隻為一個消費者維護資訊。
4.3 用戶端使用
資料格式已經在前文給出，canal和dts用戶端均采取：
拉取事件 -> 消費 -> 消費成功後ack
這樣的消費模式，并支援消費不成功時進行rollback，重新消費該資料。
下面是一段簡單的用戶端調用執行個體（略去異常處理）：
5.總結分析
5.1 優點
1）性能優異、功能全面
canal 1.1.x 版本（release_note）,性能與功能層面有較大的突破,重要提升包括:
整體性能測試&優化,提升了150%。
原生支援prometheus監控。
原生支援kafka消息投遞。
原生支援aliyun rds的binlog訂閱 (解決自動主備切換/oss binlog離線解析) （無法拒絕它的理由！）
原生支援docker鏡像。
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管理平台。
原創：阿丸筆記
本文分享自微信公衆号 - 阿丸筆記（aone_note）。
如有侵權，請删除。