Canal架構
Caner Server
一個Caner Server就代表一個canal運行實例，其對應於一個jvm
一個Caner Server同時對應着n個instance
一個instance對應着一個Mysql實例
Instance組成
一個instance由 EventParser eventSink eventStore MetaManager 這幾部分組成
eventParser
數據源接入，模擬slave協議和master進行交互，協議解析，對應的解析過程爲:
1: Connection獲取上一次解析成功的位置 (如果第一次啓動，則獲取初始指定的位置或者是當前數據庫的binlog位點)
2: Connection建立鏈接，發送BINLOG_DUMP指令
3: Mysql開始推送Binaly Log
4: 接收到的Binaly Log的通過Binlog parser進行協議解析，補充一些特定信息
5: 傳遞給EventSink模塊進行數據存儲，是一個阻塞操作，直到存儲成功
6: 存儲成功後，定時記錄Binaly Log位置
eventSink
Parser和Store鏈接器，進行數據過濾，加工，分發的工作
具體可分爲:
數據過濾:支持通配符的過濾模式，表名、字段內容等
數據路由/分發:解決1:n (1個parser對應多個store的模式)
數據歸併:解決n:1 (多個parser對應1個store)
數據加工:在進入store之前進行額外的處理，比如join
eventStore
1.Memory內存
2.本地file存儲
3.持久化到zookeeper以保障數據集羣共享
MetaManager
主要用於保存Parser組件、CanalServer（即本文中提到的NettyServer）、Canal Instances的meta數據，其中Parser組件涉及到的binlog position、CanalServer與消費者交互時ACK的Cursor信息、instance的集羣運行時信息等。
canal與mysql連接流程
1.canal模擬mysql slave的交互協議，僞裝自己爲mysql slave，向mysql master發送dump協議
2.mysql master收到dump請求，開始推送binary log給slave(也就是canal)
3.canal解析binary log對象(原始爲byte流)
canal僞裝成slave同步binlog流程
1.連接mysql,通過提供的ip和port，用Socket直接連接mysql
2.解析握手信息
當連接上後，Master會立刻回消息給Slave,如果失敗，會返回錯誤信息，如果成功則返回必要的握手信息。握手信息裏面的數據在後面通信過程中會使用，需要進行保存
3.發送認證消息
收到握手消息表示連接成功了，現在要同Master建立一個安全的連接，需要將用戶名和密碼發送給Master
4.解析認證消息
5.發送323認證請求
6.解析323返回消息
7.發送數據庫連接參數
8.解析參數設置結果
9.發送獲取checkSum的消息
10.解析結果，記錄checksum
11.發送獲取binlog位置信息
發送查詢請求給Master,查詢內容爲“show master status”
12.解析消息，獲得位置
13.發送同步binlog請求
14.啓動讀取線程，循環讀取
canal client & server簡單連接流程
1:canal client與canal server之間是C/S模式的通信，客戶端採用NIO，服務端採用Netty
2:canal server啓動後，如果沒有canal client，那麼canal server不會去mysql拉取binlog
3:即Canal客戶端主動發起拉取請求，服務端纔會模擬一個MySQL Slave節點去主節點拉取binlog
4:通常Canal客戶端是一個死循環，這樣客戶端一直調用get方法，服務端也就會一直拉取binlog。
