Canal——原理架構及應用場景

 

Canal簡介

Canal是阿里開源的一款基於Mysql數據庫binlog的增量訂閱和消費組件，通過它可以訂閱數據庫的binlog日志，然后進行一些數據消費，如數據鏡像、數據異構、數據索引、緩存更新等。相對於消息隊列，通過這種機制可以實現數據的有序化和一致性。

github地址：https://github.com/alibaba/canal

完整wiki地址：https://github.com/alibaba/canal/wiki

 

Canal工作原理

原理相對比較簡單：

1. canal模擬mysql slave與mysql master的交互協議，偽裝自己是一個mysql slave，向mysql master發送dump協議；
2. mysql master收到mysql slave（canal）發送的dump請求，開始推送binlog增量日志給slave(也就是canal)；
3. mysql slave（canal偽裝的）收到binlog增量日志后,就可以對這部分日志進行解析，獲取主庫的結構及數據變更；

 

Mysql主從同步原理

canal工作原理其實也是基於mysql主從同步原理的，所以理解mysql主從同步原理是第一步

　　  同步原理：

1. Master主庫，啟動Binlog機制，將變更數據寫入Binlog文件；
2. Slave（I/O thread），從Master主庫拉取binlon數據，將它拷貝到Slave的中繼日志(relay log)中；
3. Slave（SQL thread），回放Binlog，更新從庫數據；

　　 啟用Binlog注意以下幾點：

1. Master主庫一般會有多台Slave訂閱，且Master主庫要支持業務系統實時變更操作，服務器資源會有瓶頸；
2.  需要同步的數據表一定要有主鍵；

 

Canal架構

說明：
server代表一個canal運行實例，對應於一個jvm
instance對應於一個數據隊列

instance模塊：
eventParser (數據源接入，模擬slave協議和master進行交互，協議解析)
eventSink (Parser和Store鏈接器，進行數據過濾，加工，分發的工作)
eventStore (數據存儲)
metaManager (增量訂閱&消費信息管理器)

 

Canal-HA機制

canal是支持HA的，其實現機制也是依賴zookeeper來實現的，用到的特性有watcher和EPHEMERAL節點(和session生命周期綁定)，與HDFS的HA類似。

canal的ha分為兩部分，canal server和canal client分別有對應的ha實現

• canal server: 為了減少對mysql dump的請求，不同server上的instance(不同server上的相同instance)要求同一時間只能有一個處於running，其他的處於standby狀態(standby是instance的狀態)。
• canal client: 為了保證有序性，一份instance同一時間只能由一個canal client進行get/ack/rollback操作，否則客戶端接收無法保證有序。

server ha的架構圖如下：

大致步驟：

1. canal server要啟動某個canal instance時都先向zookeeper_進行一次嘗試啟動判斷_(實現：創建EPHEMERAL節點，誰創建成功就允許誰啟動)
2. 創建zookeeper節點成功后，對應的canal server就啟動對應的canal instance，沒有創建成功的canal instance就會處於standby狀態。
3. 一旦zookeeper發現canal server A創建的instance節點消失后，立即通知其他的canal server再次進行步驟1的操作，重新選出一個canal server啟動instance。
4. canal client每次進行connect時，會首先向zookeeper詢問當前是誰啟動了canal instance，然后和其建立鏈接，一旦鏈接不可用，會重新嘗試connect。

Canal Client的方式和canal server方式類似，也是利用zookeeper的搶占EPHEMERAL節點的方式進行控制.

 

Canal應用場景

　　1、同步緩存redis/全文搜索ES

　　canal一個常見應用場景是同步緩存/全文搜索，當數據庫變更后通過binlog進行緩存/ES的增量更新。當緩存/ES更新出現問題時，應該回退binlog到過去某個位置進行重新同步，並提供全量刷新緩存/ES的方法，如下圖所示。

 

　　2、下發任務

　　另一種常見應用場景是下發任務，當數據變更時需要通知其他依賴系統。其原理是任務系統監聽數據庫變更，然后將變更的數據寫入MQ/kafka進行任務下發，比如商品數據變更后需要通知商品詳情頁、列表頁、搜索頁等先關系統。這種方式可以保證數據下發的精確性，通過MQ發送消息通知變更緩存是無法做到這一點的，而且業務系統中不會散落着各種下發MQ的代碼，從而實現了下發歸集，如下圖所示。

 

　　3、數據異構

　　在大型網站架構中，DB都會采用分庫分表來解決容量和性能問題，但分庫分表之后帶來的新問題。比如不同維度的查詢或者聚合查詢，此時就會非常棘手。一般我們會通過數據異構機制來解決此問題。

所謂的數據異構，那就是將需要join查詢的多表按照某一個維度又聚合在一個DB中。讓你去查詢。canal就是實現數據異構的手段之一。

 

 

 

引用：

https://www.cnblogs.com/huangxincheng/p/7456397.html