[TOC] > 本部分，我們來解讀一下Canal的源碼，看從中能汲取到多少營養呢。 ## Canal簡介  ## Canal模塊介紹 下面先通過一張圖來說明各個模塊之間的依賴關系：  通過deployer模塊，啟動一個canal-server，一個cannal-server內部包含多個instance，每個instance都會偽裝成一個mysql實例的slave。client與server之間的通信協議由protocol模塊定義。client在訂閱binlog信息時，需要傳遞一個destination參數，server會根據這個destination確定由哪一個instance為其提供服務。 ### 模塊說明 模塊雖多，但是每個模塊的代碼都很少。各個模塊的作用如下所示： | 模塊名稱 | 說明 | | --- | --- | |common模塊|主要是提供了一些公共的工具類和接口。| |client模塊|canal的客戶端誦慕涌諼狢analConnector| |example模塊|提供client模塊使用案例。| |protocol模塊|client和server模塊之間的通信協議| |deployer|部署模塊。通過該模塊提供的CanalLauncher來啟動canal server| |server模塊|canal服務器端誦慕涌諼狢analServer| |instance模塊|一個server有多個instance。每個instance都會模擬成一個mysql實例的slave。instance模塊有四個核心組成部分，parser模塊、sink模塊、store模塊，meta模塊| |parser模塊|數據源接入，模擬slave協議和master進行交互，協議解析。parser模塊依賴于dbsync、driver模塊。| |driver模塊和dbsync模塊|從這兩個模塊的artifactId(canal.parse.driver、canal.parse.dbsync)，就可以看出來，這兩個模塊實際上是parser模塊的組件。事實上parser 是通過driver模塊與mysql建立連接，從而獲取到binlog。由于原始的binlog都是二進制流，需要解析成對應的binlog事件，這些binlog事件對象都定義在dbsync模塊中，dbsync 模塊來自于淘寶的tddl。| |sink模塊|parser和store鏈接器，進行數據過濾，加工，分發的工作誦慕涌諼狢analEventSink| |store模塊|數據存儲。核心接口為CanalEventStore| |meta模塊|增量訂閱&消費信息管理器，核心接口為`CanalMetaManager`，主要用于記錄canal消費到的mysql binlog的位置。| ## Canal和Otter什么關系？ 借鑒網友的一張圖：  mysql的自帶復制技術可分成三步： 1. master將改變記錄到二進制日志(binary log)中（這些記錄叫做二進制日志事件，binary log events，可以通過show binlog events進行查看）； 2. slave將master的binary log events拷貝到它的中繼日志(relay log)，這里是I/O thread線程； 3. slave重做中繼日志中的事件，將改變反映它自己的數據，這里是SQL thread線程。 基于canal&otter的復制技術和mysql復制類似，具有類比性： 1. Canal對應于I/O thread，接收Master Binary Log； 2. Otter對應于SQL thread，通過Canal獲取Binary Log數據，執行同步插入數據庫； ### 提問與分析： 從兩張圖中，我們可以注意到一個細節不同：圖一Slave獲取Binlog是一個`pull模式`；圖二的描述卻是`push模式`。 既然是偽裝，數據同步的方式應該是一致的才是，所以上圖可能存在一定的錯誤。 ### 兩者的區別在于： otter目前嵌入式依賴canal，部署為同一個jvm，目前設計為不產生Relay Log，數據不落地； otter目前允許自定義同步邏輯，解決各類需求； a. ETL轉化. 比如Slave上目標表的表名，字段名，字段類型不同，字段個數不同等. b. 異構數據庫. 比如Slave可以是oracle或者其他類型的存儲,nosql等. c. M-M部署，解決數據一致性問題 d. 基于manager部署，方便監控同步狀態和管理同步任務. ## 參考資料： [canal和otter的關系？](https://blog.csdn.net/liupeifeng3514/article/details/79687130)