>作者：幻好
>來源：[恆生LIGHT雲社群](https://developer.hs.net/thread/1236)

> 隨著系統業務量的不斷擴大，都會使用分散式的方式，同時會有非常多的中介軟體，如redis、訊息佇列、大資料儲存等，但是實際核心的資料儲存依然是儲存在資料庫，多個資料庫之前就會存在資料實時同步的問題，為了解決這個問題，需要採用一些資料實時同步中介軟體來解決問題。

### Canal簡介

`Canal`是阿里開源的一款基於 `Mysql`資料庫 `binlog`的增量訂閱和消費元件，透過它可以訂閱資料庫的 `binlog`日誌，然後進行一些資料消費，如資料映象、資料異構、資料索引、快取更新等。相對於訊息佇列，透過這種機制可以實現資料的有序化和一致性。

### 設計背景

早期，阿里巴巴B2B公司因為存在杭州和美國雙機房部署，存在跨機房同步的業務需求。不過早期的資料庫同步業務，主要是基於trigger的方式獲取增量變更，不過從2010年開始，阿里系公司開始逐步的嘗試基於資料庫的日誌解析，獲取增量變更進行同步，由此衍生出了增量訂閱&消費的業務，從此開啟了一段新紀元。

目前內部使用的同步，已經支援mysql5.x和oracle部分版本的日誌解析。

基於日誌增量訂閱&消費支援的業務：

1. 資料庫映象
2. 資料庫實時備份
3. 多級索引 (賣家和買家各自分庫索引)
4. search build
5. 業務cache重新整理
6. 價格變化等重要業務訊息

### 工作原理

#### mysql主備複製實現

![687474703a2f2f646c2e69746579652e636f6d2f75706c6f61642f6174746163686d656e742f303038302f333038362f34363863316131342d653761642d333239302d396433642d3434616335303161373232372e6a7067.jpg](https://developer.hs.net/storage/attachments/2021/07/25/P2Z7lB7DZVXyJ1zc5AsQFshMOiENdfDxawrcEKOx_thumb.jpg "2358")
從上層來看，複製分成三步：

1. `master`將改變記錄到二進位制日誌(`binary log`)中（這些記錄叫做二進位制日誌事件，`binary log events`，可以透過`show binlog events`進行檢視）；
2. `slave`將`master`的`binary log events`複製到它的中繼日誌(`relay log`)；
3. `slave`重做中繼日誌中的事件，將改變反映它自己的資料。

#### canal的工作原理

![687474703a2f2f646c2e69746579652e636f6d2f75706c6f61642f6174746163686d656e742f303038302f333130372f63383762363762612d333934632d333038362d393537372d3964623035626530346339352e6a7067.jpg](https://developer.hs.net/storage/attachments/2021/07/25/CTLxyg6KVz0IZvA15azGbFqXHGxxmGMoB0Wvxg0C_thumb.jpg "2357")

原理相對比較簡單：

1. `canal`模擬`mysql slave`的互動協議，偽裝自己為`mysql slave`，向`mysql master`傳送`dump`協議
2. `mysql master`收到`dump`請求，開始推送`binary log`給`slave`(也就是`canal`)
3. `canal`解析`binary log`物件(原始為byte流)

### 底層架構

![687474703a2f2f646c2e69746579652e636f6d2f75706c6f61642f6174746163686d656e742f303038302f333132362f34393535303038352d306364322d333266612d383661362d6636373664623562353937622e6a7067.jpg](https://developer.hs.net/storage/attachments/2021/07/25/TvjEvLbuJtD4sgkIaHOJw12h8N4KOdURAgq8lTc8_thumb.jpg "2356")

說明：

* `server`代表一個`canal`執行例項，對應於一個`jvm`
* `instance`對應於一個資料佇列 （1個`server`對應1..n個`instance`)

`instance`模組：

* `eventParser` (資料來源接入，模擬slave協議和master進行互動，協議解析)
* `eventSink` (Parser和Store連結器，進行資料過濾，加工，分發的工作)
* `eventStore` (資料儲存)
* `metaManager` (增量訂閱&消費資訊管理器)

#### EventParser設計

![687474703a2f2f646c2e69746579652e636f6d2f75706c6f61642f6174746163686d656e742f303038302f333134332f37393531633136392d663764662d336362332d616562622d6439323466353733313163622e6a7067.jpg](https://developer.hs.net/storage/attachments/2021/07/25/I5o7k0b51Z8YjzlPU5ILLziRp2bFn89LUGZYblBs_thumb.jpg "2355")

整個 `parser`過程大致可分為幾步：

1. `Connection`獲取上一次解析成功的位置 (如果第一次啟動，則獲取初始指定的位置或者是當前資料庫的`binlog`位點)
2. `Connection`建立連結，傳送`BINLOG_DUMP`指令
   // 0. write command number
   // 1. write 4 bytes bin-log position to start at
   // 2. write 2 bytes bin-log flags
   // 3. write 4 bytes server id of the slave
   // 4. write bin-log file name
3. `Mysql`開始推送`Binaly Log`
4. 接收到的`Binaly Log`的透過`Binlog parser`進行協議解析，補充一些特定資訊
   // 補充欄位名字，欄位型別，主鍵資訊，unsigned型別處理
5. 傳遞給`EventSink`模組進行資料儲存，是一個阻塞操作，直到儲存成功
6. 儲存成功後，定時記錄`Binaly Log`位置

#### EventSink設計

![687474703a2f2f646c2e69746579652e636f6d2f75706c6f61642f6174746163686d656e742f303038302f333231342f30613266643637312d643665392d336564372d623131302d3661336237333861336362302e6a7067.jpg](https://developer.hs.net/storage/attachments/2021/07/25/dZUTedEZAyp29fN9qLNZVSBGBQ41zBDUzAm2x4Ry_thumb.jpg "2354")

說明：

* 資料過濾：支援萬用字元的過濾模式，表名，欄位內容等
* 資料路由/分發：解決1:n (1個`parser`對應多個`store`的模式)
* 資料歸併：解決n:1 (多個`parser`對應1個`store`)
* 資料加工：在進入`store`之前進行額外的處理，比如`join`

#### EventStore設計

* 1.目前僅實現了`Memory`記憶體模式，後續計劃增加本地`file`儲存，`mixed`混合模式
* 2.借鑑了`Disruptor`的`RingBuffer`的實現思路

`RingBuffer`設計：

![687474703a2f2f646c2e69746579652e636f6d2f75706c6f61642f6174746163686d656e742f303038302f333233372f30363365383438302d313563382d336536362d626264332d3963343464656630396338662e6a7067.jpg](https://developer.hs.net/storage/attachments/2021/07/25/6hYb2qSlpkSoVoDtpe99OuiwFfF36HhmOxJWAa5l_thumb.jpg "2353")

定義了3個cursor

* Put : Sink模組進行資料儲存的最後一次寫入位置
* Get : 資料訂閱獲取的最後一次提取位置
* Ack : 資料消費成功的最後一次消費位置

#### Instance設計

![687474703a2f2f646c2e69746579652e636f6d2f75706c6f61642f6174746163686d656e742f303038302f333234372f35646531633961662d373739382d336434322d626334332d3563353464383263346462662e6a7067.jpg](https://developer.hs.net/storage/attachments/2021/07/25/y4ZrRqNC2UrLae9eQEK9LBZAa0SYDbzBo6YGB40U_thumb.jpg "2352")

`instance`代表了一個實際執行的資料佇列，包括了 `EventPaser`,`EventSink`,`EventStore`等元件。

抽象了 `CanalInstanceGenerator`，主要是考慮配置的管理方式：

* `manager`方式： 和你自己的內部web console/manager系統進行對接。(目前主要是公司內部使用)
* `spring`方式：基於spring xml + properties進行定義，構建spring配置。

#### Server設計

![687474703a2f2f646c2e69746579652e636f6d2f75706c6f61642f6174746163686d656e742f303038302f333235372f66346466333862612d353965322d333938652d623565622d3162626662656363303637362e6a7067.jpg](https://developer.hs.net/storage/attachments/2021/07/25/kxDQbtxKe3UEbSBH8CelWVzYKgDzhdgNGXxh94wt_thumb.jpg "2351")

`server`代表了一個canal的執行例項，為了方便元件化使用，特意抽象了 `Embeded`(嵌入式) / `Netty`(網路訪問)的兩種實現

* `Embeded` : 對`latency`和可用性都有比較高的要求，自己又能hold住分散式的相關技術(比如`failover`)
* `Netty` : 基於`netty`封裝了一層網路協議，由`canal server`保證其可用性，採用的pull模型，當然`latency`會稍微打點折扣，不過這個也視情況而定。(阿里系的`notify`和`metaq`，典型的`push/pull`模型，目前也逐步的在向`pull`模型靠攏，`push`在資料量大的時候會有一些問題)

### HA機制

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

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

整個HA機制的控制主要是依賴了 `zookeeper`的幾個特性，`watcher`和 `EPHEMERAL`節點(和 `session`生命週期繫結)。

Canal Server:

![687474703a2f2f646c2e69746579652e636f6d2f75706c6f61642f6174746163686d656e742f303038302f333330332f64333230326332362d653935342d333563302d613331392d3537363034313032633537642e6a7067.jpg](https://developer.hs.net/storage/attachments/2021/07/25/9ukwZMrgPAi183echCfB4uMQXPsOkwSECYWeQPbc_thumb.jpg "2350")

大致步驟：

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

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

### 應用場景

#### 資料同步

* 微服務開發環境下，為了提高搜尋效率，以及搜尋的精準度，會大量使用`Redis`、`Mongodb`等`NoSQL`資料庫，也會使用大量的`Solr`、`Elasticsearch`等全文檢索服務。那麼，這個時候，就會有一個問題需要我們來思考和解決：那就是資料同步的問題！
* Canal可以將實時變化的資料庫中的資料同步到`Redis`,`Mongodb`或者`Solr`/`Elasticsearch`中。![20200930105843756.png](https://developer.hs.net/storage/attachments/2021/07/25/LmYETqM9Svb2Yvoayq92enGnoklwLzVDWBudR9yx_thumb.png "2349")

#### 資料異構

在大型網站架構中，DB都會採用分庫分表來解決容量和效能問題，但分庫分表之後帶來的新問題。比如不同維度的查詢或者聚合查詢，此時就會非常棘手。一般我們會透過資料異構機制來解決此問題，資料異構就是將需要join查詢的多表按照某一個維度又聚合在一個DB中。讓你去查詢。canal就是實現資料異構的手段之一。

![1577453-20191109101403531-66775627.png](https://developer.hs.net/storage/attachments/2021/07/25/4b0wW75r3czVjXKtdaaqVAEfwFyULAUV8l9qZLIh_thumb.png "2348")

認識資料實時同步神器—Canal

相關文章