1.簡介
canal [kə’næl],譯意爲水道/管道/溝渠,主要用途是基於 MySQL 數據庫增量日誌解析,提供增量數據 訂閱 和 消費。應該是阿里雲DTS(Data Transfer Service)的開源版本。
2.提供的能力
Canal與DTS提供的功能基本相似:
1)基於Mysql的Slave協議實時dump binlog流,解析爲事件發送給訂閱方。
事件格式爲(僞代碼):
Eevnt {
Header {
logfileName [binlog文件名]
logfileOffset [binlog position]
executeTime [binlog裏記錄變更發生的時間戳]
schemaName [數據庫實例]
tableName [表名]
eventType [insert/update/delete類型]
}
entryType [事務頭BEGIN/事務尾END/數據ROWDATA]
storeValue [byte數據,可展開,對應的類型爲RowChange]
isDdl [是否是ddl變更操作,比如create table/drop table]
sql [具體的ddl sql]
rowDatas [具體insert/update/delete的變更數據,可爲多條,1個binlog event事件可對應多條變更,比如批處理]
beforeColumns [Column類型的數組]
afterColumns [Column類型的數組]
}
Column {
index [column序號]
sqlType [jdbc type]
name [column name]
isKey [是否爲主鍵]
updated [是否發生過變更]
isNull [值是否爲null]
value [具體的值]
}
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組成;
- 每個server代表一個canal-server運行實例jvm;
- 每個server上可以運行一個或多個Instance;
- 每個Instance對應於一個數據隊列,是真正的變更抓取的實體
1) Instance子模塊
- EventParser :數據源接入,模擬MySQL slave協議從master上dump binlog,並進行解析
- EventSink :對dump的數據進行過濾、加工、分發,連接Parser和Store
- EventStore :對sink模塊處理後的數據進行臨時存儲
- MetaManager:元數據管理器
2) EventParser子模塊
主要有兩個核心組件組成:
- CanalLogPositionManager:用來記錄最新解析成功的binlog position信息,在canal重啓後,作爲起始位點
- CanalHAController:支持Mysql主備,基於Heartbeat判斷當前數據庫連接的有效性,一旦主庫失去心跳,就切換連接備庫
EventParser從CanalHAController確定連接mysql的位置,然後通過LogPositionManager確定binlog解析位點的起點,最後便通過dump協議拉取binlog進行解析,把解析後的消息存入EventSink
3)EventSink子模塊
目前只有一個實現類GroupEventSink,用來把多個instance上的數據進行歸併,主要用於分庫後的多數據歸併。
4)EventStore子模塊
目前只實現了基於內存存儲的MemoryEventStoreWIthBuffer,據說很多年前就聲稱要支持基於文件存儲的實現,不過到現在還沒有具體的實現類。
MemoryEventStoreWIthBuffer內部採用的是一個RingBuffer,我們可以理解爲基於內存的高性能消息隊列。如果使用canal-client直接消費canal-server的數據,那麼只能通過這個消息隊列做一定程度的消息堆積。
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%
- 原生支持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管理平臺,記得關注哦。
看到這裏了,原創不易,點個贊吧,你最好看了~
知識碎片重新梳理,構建Java知識圖譜:https://github.com/saigu/JavaKnowledgeGraph (歷史文章查閱非常方便)