CanalInstance設(shè)計理念與定制開發(fā)思路是什么

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

1、Canal Instance 類繼承體系

 

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

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

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

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

• CanalEventStore getEventStore()
  事件存儲器，即 Canal Instance 作為 MySQL 的 "Slave" 服務(wù)器，需要將同步過來的數(shù)據(jù)進(jìn)行存儲，然后被 Canal 的客戶端最終會從 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)類。

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

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

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

2、CanalInstance 四大核心組件

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

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

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

 

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

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

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

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

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

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

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

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

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

 

 

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

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

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

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