轉自：https://www.jianshu.com/p/0ccbd1a1a5ec
一、整體架構
canal架構圖.png
canal架構圖2.png
說明：
- server代表一個canal運行實例，對應於一個jvm
- instance對應於一個數據隊列 （1個server對應1..n個instance)
instance模塊：
- eventParser (數據源接入，模擬slave協議和master進行交互，協議解析)
- eventSink (Parser和Store鏈接器，進行數據過濾，加工，分發的工作)
- eventStore (數據存儲)
- metaManager (增量訂閱&消費信息管理器)
二、各模塊架構
2.1 Parser
EventParser架構.png
整個parser過程大致可分爲幾步：
- Connection獲取上一次解析成功的位置（如果第一次啓動，則獲取初始制定的位置或者是當前數據庫的binlog位點）
- Connection建立連接，發生BINLOG_DUMP命令
- Mysql開始推送Binary Log
- 接收到的Binary Log通過Binlog parser進行協議解析，補充一些特定信息
- 傳遞給EventSink模塊進行數據存儲，是一個阻塞操作，直到存儲成功
- 存儲成功後，定時記錄Binary Log位置
2.2 Sink
Sink.png
說明：
- 數據過濾：支持通配符的過濾模式，表名，字段內容等
- 數據路由/分發：解決1:n (1個parser對應多個store的模式)
- 數據歸併：解決n:1 (多個parser對應1個store)
- 數據加工：在進入store之前進行額外的處理，比如join
1 數據1:n業務 ：
爲了合理的利用數據庫資源， 一般常見的業務都是按照schema進行隔離，然後在mysql上層或者dao這一層面上，進行一個數據源路由，屏蔽數據庫物理位置對開發的影響，阿里系主要是通過cobar/tddl來解決數據源路由問題。 所以，一般一個數據庫實例上，會部署多個schema，每個schema會有由1個或者多個業務方關注。
2 數據n:1業務：
同樣，當一個業務的數據規模達到一定的量級後，必然會涉及到水平拆分和垂直拆分的問題，針對這些拆分的數據需要處理時，就需要鏈接多個store進行處理，消費的位點就會變成多份，而且數據消費的進度無法得到儘可能有序的保證。 所以，在一定業務場景下，需要將拆分後的增量數據進行歸併處理，比如按照時間戳/全局id進行排序歸併.
2.3 Store
目前實現了Memory內存、本地file存儲以及持久化到zookeeper以保障數據集羣共享。
Memory內存的RingBuffer設計：
store ringBuffer.png
定義了3個cursor
- Put : Sink模塊進行數據存儲的最後一次寫入位置
- Get : 數據訂閱獲取的最後一次提取位置
- Ack : 數據消費成功的最後一次消費位置
借鑑Disruptor的RingBuffer的實現，將RingBuffer拉直來看：
store ringBuffer2.png
實現說明：
Put/Get/Ack cursor用於遞增，採用long型存儲
buffer的get操作，通過取餘或者與操作。(與操作： cusor & (size – 1) , size需要爲2的指數，效率比較高)
作者：端木軒
鏈接：https://www.jianshu.com/p/0ccbd1a1a5ec
來源：簡書
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。
