Instance 是 Canal 數(shù)據(jù)同步的核心，在一個(gè) Canal 實(shí)例中只有啟動(dòng) Instace，才能實(shí)現(xiàn)數(shù)據(jù)的同步，那 Instance 到底是“何許人也”，以源碼為手段，試圖揭開(kāi) Instance 的神秘面紗。

1、Canal Instance 類(lèi)繼承體系

 

• CanalInstanceCanal Instance 接口，即定義 Instance 的基本特征，主要定義如下方法：

• String getDestination()
  實(shí)例的目的地名稱(chēng)，在 Canal 中表示一個(gè)源實(shí)例名稱(chēng)，對(duì)應(yīng)一個(gè) MySQL 實(shí)例信息，例如 192.168.1.3:3306，這里為該實(shí)例取一個(gè)名稱(chēng)。

• CanalEventParser getEventParser()
  事件解析器，即 Binlog 解析器，負(fù)責(zé)解析 binlog 日志。

• CanalEventSink getEventSink()
  EventParse 與 EventStore 的連接器，主要處理數(shù)據(jù)的過(guò)濾、加工與分發(fā)，即提供了對(duì) binlog 原始數(shù)據(jù)進(jìn)行“加工”的切入點(diǎn)，EventStore 存儲(chǔ)的就是經(jīng) EventSink處理過(guò)的數(shù)據(jù)。

• CanalEventStore getEventStore()
  事件存儲(chǔ)器，即 Canal Instance 作為 MySQL 的 "Slave" 服務(wù)器，需要將同步過(guò)來(lái)的數(shù)據(jù)進(jìn)行存儲(chǔ)，然后被 Canal 的客戶(hù)端最終會(huì)從 EventStore 中獲取數(shù)據(jù)，目前 Canal 只實(shí)現(xiàn)了基于內(nèi)存的 EventStore，那 Canal 是如何避免內(nèi)存泄露，并且如何避免數(shù)據(jù)丟失的，這將是后續(xù)我們需要研究的重點(diǎn)。

• CanalMetaManager getMetaManager()
  Canal 元數(shù)據(jù)管理器，例如記錄 消費(fèi)端消費(fèi)進(jìn)度，即從 Canal EventStore 中處理數(shù)據(jù)的情況。

• CanalAlarmHandler getAlarmHandler()
  告警服務(wù)。

• AbstractCanalInstance
  CanalInstance的抽象實(shí)現(xiàn)類(lèi)。

• CanalInstanceWithManager
  基于手動(dòng)編程式的 CanaInstance，主要通過(guò)API的方式手動(dòng)生成 CanalInstance 實(shí)例?？梢灶?lèi)比 Spring 基于編程API 的事務(wù)管理器。

• CanalInstanceWithSpring
  基于 Spring 方式構(gòu)建 CanaInstance。

• CanalInstanceGenerator
  Canal Instance 的構(gòu)造類(lèi)體系，即通過(guò)該類(lèi)提供的方法創(chuàng)建 CanalInstance 實(shí)例，提供基于 Spring、手動(dòng)管理等方式。

2、CanalInstance 四大核心組件

從類(lèi)層次了解 Canal Instance 顯得不那么直觀，接下來(lái)先拋出一個(gè)使用場(chǎng)景，再結(jié)合架構(gòu)圖進(jìn)一步加深對(duì) Canal Instance 的理解。

例如某公司的訂單系統(tǒng)使用了分庫(kù)分表，數(shù)據(jù)庫(kù)的分別部署在 192.168.1.166:3306，192.168.1.168:3306 兩個(gè)數(shù)據(jù)庫(kù)，并且每一個(gè)數(shù)據(jù)庫(kù)上會(huì)創(chuàng)建多個(gè) schema，例如 order_db、user_db，那現(xiàn)在為了對(duì)訂單提供多維度的查詢(xún)，統(tǒng)計(jì)等功能，架構(gòu)組因此提出通過(guò)訂閱數(shù)據(jù)庫(kù) binlog 日志，將兩個(gè)訂單庫(kù)中的訂單數(shù)據(jù)，即將 order_db 中的數(shù)據(jù)同步到 elasticsearch，而 Canal 的設(shè)計(jì)初衷就是為了解決上述問(wèn)題，故我們可以邊思考這個(gè)場(chǎng)景，來(lái)反推一下 Canal Instance 的設(shè)計(jì)理念。

Canal Instance 的架構(gòu)圖如下圖所示：

 

每一個(gè) CanalInstance 可以看成是對(duì)應(yīng)一個(gè) MySQL 實(shí)例，即案例中需要同步兩個(gè)數(shù)據(jù)庫(kù)實(shí)例，故最終需要?jiǎng)?chuàng)建兩個(gè) CanalInstance。其實(shí)也不難理解，因?yàn)?MySQL 的 binlog 就是以實(shí)例為維度進(jìn)行存儲(chǔ)的。Canal Instance 包含了 4個(gè) 核心組件 ：EventParse、EventSink、EventStore、CanaMetaManager，在這里主要是闡明其作用，后續(xù)文章會(huì)一一詳細(xì)介紹，以便更好的指導(dǎo)實(shí)踐。

• EventParse 組件
  負(fù)責(zé)解析 binlog日志，其職責(zé)就是根據(jù) binlog 的存儲(chǔ)格式將有效數(shù)據(jù)提取出來(lái)，這個(gè)不難理解，我們也可以通過(guò)該模塊，進(jìn)一步了解一下 binglog 的存儲(chǔ)格式。

• EventSink 組件
  結(jié)合數(shù)據(jù)同步案例，在一個(gè)數(shù)據(jù)庫(kù)實(shí)例上通常會(huì)創(chuàng)建多個(gè) Schema，但通常并不是所有的 schema 都需要被同步，如果直接將 EventParse 解析出來(lái)的數(shù)據(jù)全部傳入EventStore 組件，將對(duì) EventStore 帶來(lái)不必要的性能消耗；另外本例中使用了分庫(kù)分表，需要將多個(gè)庫(kù)的數(shù)據(jù)同步到單一源，可能需要涉及到合并、歸并等策略。以上等等等需求就是 EventSink 需要解決的問(wèn)題域。

• EventStore 組件
  用來(lái)存儲(chǔ)經(jīng) canal 轉(zhuǎn)換的數(shù)據(jù)，被 Canal Client 進(jìn)行消費(fèi)的數(shù)據(jù)，目前 Canal 只提供了基于內(nèi)存的存儲(chǔ)實(shí)現(xiàn)。大家不妨先思考一下，采用基于內(nèi)存的存儲(chǔ)模式，如何避免內(nèi)存溢出，其具體實(shí)現(xiàn)將在后續(xù)文章中詳細(xì)剖析。

• CanalMetaManager 組件
  元數(shù)據(jù)存儲(chǔ)管理器。在 Canal 中最基本的元數(shù)據(jù)至少應(yīng)該包含 EventParse 組件解析的位點(diǎn)與消費(fèi)端的消費(fèi)位點(diǎn)。Canal Server 重啟后要能從上一次未同步位置開(kāi)始同步，否則會(huì)丟失數(shù)據(jù)。在將數(shù)據(jù)庫(kù)數(shù)據(jù)同步到 es 的示例中，所謂的 canal 客戶(hù)端就是從 Canal Server 即 EventStore 中獲取數(shù)據(jù)，并將數(shù)據(jù)寫(xiě)入 es 中，并上報(bào)寫(xiě)入進(jìn)度，這些信息都是由 CanalMetaManager 組件完成。

從最新的版本來(lái)看，Canal 支持直接將解析后的數(shù)據(jù)發(fā)送到MQ，故 CanalInstance 中還持有另外一個(gè)組件：CanalMQConfig，關(guān)于 MQ 的一些配置，提供了多種策略實(shí)現(xiàn) shcema、table 到 MQ Topic 的自動(dòng)映射管理，為 Canal 的使用者帶來(lái)更多便利，這部分內(nèi)容會(huì)在后續(xù)文章中單獨(dú)介紹，這里先暫時(shí)不過(guò)多討論。

經(jīng)過(guò)上面的了解，我想大家對(duì) Canal Instance 有了一個(gè)相對(duì)全面的了解了吧，接下來(lái)我們?cè)賮?lái)關(guān)注一下 CanalInstance 的構(gòu)造方式，這個(gè)對(duì)后續(xù)的實(shí)踐有著非常重要的影響。

3、CanalInstance 構(gòu)造方式

Canal 中提供了兩種方式對(duì) Instance 進(jìn)行初始化：Spring 與 手動(dòng)編程方式。CanalInstance 最最核心的就是上述提到的4個(gè)組件，即 CanalInstanceWithManager 類(lèi)的具體職責(zé)就是管理上述核心組件，即提供對(duì)上述組件的加載、啟動(dòng)、停止，并協(xié)調(diào)，從其名字就能看出來(lái)，從其構(gòu)造函數(shù)同樣能得知：

 

 

溫馨提示：基于 Canal 二次開(kāi)發(fā)的編程技巧思考如下：Canal 框架本身將 Canal Server 做成了啟動(dòng)腳本，可以通過(guò)自定義 Instance，即從 instance 配置文件中加載配置，然后啟動(dòng) Canal Server 解析 Binlog 日志，最終按照預(yù)定的配置進(jìn)行工作，例如在生產(chǎn)環(huán)境搭建一些 Canal 集群，統(tǒng)一交由運(yùn)維去手動(dòng)維護(hù)，如果需要數(shù)據(jù)同步，則配置相應(yīng)的 instance 文件，然后進(jìn)行啟動(dòng)就生效，其實(shí)這種模式處于 Canal 的初階階段，更好的方式是對(duì) Canal 進(jìn)行二次開(kāi)發(fā)，通過(guò)可視化的界面，通過(guò)界面的方式定義數(shù)據(jù)同步任務(wù)，例如將指定數(shù)據(jù)庫(kù)實(shí)例上的指定 Schema 的 binglog 日志同步到指定消息集群的指定 topic，并且可重推、隨時(shí)停止，重啟，這樣 Canal 的維護(hù)者無(wú)需關(guān)注底層的細(xì)節(jié)，只需要通過(guò)頁(yè)面簡(jiǎn)單配置一下即可。

源碼 Canal 系列的第一篇文章后有好幾個(gè)粉絲表示目前也在研究 Canal，由于筆者目前只能盡量保持周更，如果大家希望加快研究 Canal 的步伐，筆者有如下建議：

1、深入研究其四大核心組件，并帶著問(wèn)題去研究，例如在學(xué)習(xí)元數(shù)據(jù)管理時(shí)是如何保證數(shù)據(jù)不丟失，重啟后又是如何定位位點(diǎn)的。

2、如果大家想更全局的去研究 Canal，我覺(jué)得除了閱讀 Canal 官方的設(shè)計(jì)手冊(cè)，還可以專(zhuān)門(mén)去看一下 CanalParameter 這個(gè)類(lèi)，Canal 支持的所有配置屬性，并且都有相應(yīng)的注釋?zhuān)P(guān)于 Canal 的所有一切，都可以從這里窺探出端倪，然后可以選擇感興趣的內(nèi)容加以繼續(xù)深入學(xué)習(xí)。