這篇文章將為大家詳細(xì)講解有關(guān)Canal Instance 設(shè)計理念與定制開發(fā)思路是什么,文章內(nèi)容質(zhì)量較高,因此小編分享給大家做個參考,希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。
創(chuàng)新互聯(lián)堅持“要么做到,要么別承諾”的工作理念,服務(wù)領(lǐng)域包括:成都網(wǎng)站設(shè)計、成都做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務(wù),滿足客戶于互聯(lián)網(wǎng)時代的裕安網(wǎng)站設(shè)計、移動媒體設(shè)計的需求,幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴!
Instance 是 Canal 數(shù)據(jù)同步的核心,在一個 Canal 實例中只有啟動 Instace,才能實現(xiàn)數(shù)據(jù)的同步,那 Instance 到底是“何許人也”,以源碼為手段,試圖揭開 Instance 的神秘面紗。
CanalInstanceCanal Instance 接口,即定義 Instance 的基本特征,主要定義如下方法:
String getDestination()
實例的目的地名稱,在 Canal 中表示一個源實例名稱,對應(yīng)一個 MySQL 實例信息,例如 192.168.1.3:3306,這里為該實例取一個名稱。
CanalEventParser getEventParser()
事件解析器,即 Binlog 解析器,負(fù)責(zé)解析 binlog 日志。
CanalEventSink getEventSink()
EventParse 與 EventStore 的連接器,主要處理數(shù)據(jù)的過濾、加工與分發(fā),即提供了對 binlog 原始數(shù)據(jù)進行“加工”的切入點,EventStore 存儲的就是經(jīng) EventSink處理過的數(shù)據(jù)。
CanalEventStore getEventStore()
事件存儲器,即 Canal Instance 作為 MySQL 的 "Slave" 服務(wù)器,需要將同步過來的數(shù)據(jù)進行存儲,然后被 Canal 的客戶端最終會從 EventStore 中獲取數(shù)據(jù),目前 Canal 只實現(xiàn)了基于內(nèi)存的 EventStore,那 Canal 是如何避免內(nèi)存泄露,并且如何避免數(shù)據(jù)丟失的,這將是后續(xù)我們需要研究的重點。
CanalMetaManager getMetaManager()
Canal 元數(shù)據(jù)管理器,例如記錄 消費端消費進度,即從 Canal EventStore 中處理數(shù)據(jù)的情況。
CanalAlarmHandler getAlarmHandler()
告警服務(wù)。
AbstractCanalInstance
CanalInstance的抽象實現(xiàn)類。
CanalInstanceWithManager
基于手動編程式的 CanaInstance,主要通過API的方式手動生成 CanalInstance 實例。可以類比 Spring 基于編程API 的事務(wù)管理器。
CanalInstanceWithSpring
基于 Spring 方式構(gòu)建 CanaInstance。
CanalInstanceGenerator
Canal Instance 的構(gòu)造類體系,即通過該類提供的方法創(chuàng)建 CanalInstance 實例,提供基于 Spring、手動管理等方式。
從類層次了解 Canal Instance 顯得不那么直觀,接下來先拋出一個使用場景,再結(jié)合架構(gòu)圖進一步加深對 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ù)據(jù)庫實例,故最終需要創(chuàng)建兩個 CanalInstance。其實也不難理解,因為 MySQL 的 binlog 就是以實例為維度進行存儲的。Canal Instance 包含了 4個 核心組件 :EventParse、EventSink、EventStore、CanaMetaManager,在這里主要是闡明其作用,后續(xù)文章會一一詳細(xì)介紹,以便更好的指導(dǎo)實踐。
EventParse 組件
負(fù)責(zé)解析 binlog日志,其職責(zé)就是根據(jù) binlog 的存儲格式將有效數(shù)據(jù)提取出來,這個不難理解,我們也可以通過該模塊,進一步了解一下 binglog 的存儲格式。
EventSink 組件
結(jié)合數(shù)據(jù)同步案例,在一個數(shù)據(jù)庫實例上通常會創(chuàng)建多個 Schema,但通常并不是所有的 schema 都需要被同步,如果直接將 EventParse 解析出來的數(shù)據(jù)全部傳入EventStore 組件,將對 EventStore 帶來不必要的性能消耗;另外本例中使用了分庫分表,需要將多個庫的數(shù)據(jù)同步到單一源,可能需要涉及到合并、歸并等策略。以上等等等需求就是 EventSink 需要解決的問題域。
EventStore 組件
用來存儲經(jīng) canal 轉(zhuǎn)換的數(shù)據(jù),被 Canal Client 進行消費的數(shù)據(jù),目前 Canal 只提供了基于內(nèi)存的存儲實現(xiàn)。大家不妨先思考一下,采用基于內(nèi)存的存儲模式,如何避免內(nèi)存溢出,其具體實現(xiàn)將在后續(xù)文章中詳細(xì)剖析。
CanalMetaManager 組件
元數(shù)據(jù)存儲管理器。在 Canal 中最基本的元數(shù)據(jù)至少應(yīng)該包含 EventParse 組件解析的位點與消費端的消費位點。Canal Server 重啟后要能從上一次未同步位置開始同步,否則會丟失數(shù)據(jù)。在將數(shù)據(jù)庫數(shù)據(jù)同步到 es 的示例中,所謂的 canal 客戶端就是從 Canal Server 即 EventStore 中獲取數(shù)據(jù),并將數(shù)據(jù)寫入 es 中,并上報寫入進度,這些信息都是由 CanalMetaManager 組件完成。
從最新的版本來看,Canal 支持直接將解析后的數(shù)據(jù)發(fā)送到MQ,故 CanalInstance 中還持有另外一個組件:CanalMQConfig,關(guān)于 MQ 的一些配置,提供了多種策略實現(xiàn) shcema、table 到 MQ Topic 的自動映射管理,為 Canal 的使用者帶來更多便利,這部分內(nèi)容會在后續(xù)文章中單獨介紹,這里先暫時不過多討論。
經(jīng)過上面的了解,我想大家對 Canal Instance 有了一個相對全面的了解了吧,接下來我們再來關(guān)注一下 CanalInstance 的構(gòu)造方式,這個對后續(xù)的實踐有著非常重要的影響。
Canal 中提供了兩種方式對 Instance 進行初始化:Spring 與 手動編程方式。CanalInstance 最最核心的就是上述提到的4個組件,即 CanalInstanceWithManager 類的具體職責(zé)就是管理上述核心組件,即提供對上述組件的加載、啟動、停止,并協(xié)調(diào),從其名字就能看出來,從其構(gòu)造函數(shù)同樣能得知:
溫馨提示:基于 Canal 二次開發(fā)的編程技巧思考如下:Canal 框架本身將 Canal Server 做成了啟動腳本,可以通過自定義 Instance,即從 instance 配置文件中加載配置,然后啟動 Canal Server 解析 Binlog 日志,最終按照預(yù)定的配置進行工作,例如在生產(chǎn)環(huán)境搭建一些 Canal 集群,統(tǒng)一交由運維去手動維護,如果需要數(shù)據(jù)同步,則配置相應(yīng)的 instance 文件,然后進行啟動就生效,其實這種模式處于 Canal 的初階階段,更好的方式是對 Canal 進行二次開發(fā),通過可視化的界面,通過界面的方式定義數(shù)據(jù)同步任務(wù),例如將指定數(shù)據(jù)庫實例上的指定 Schema 的 binglog 日志同步到指定消息集群的指定 topic,并且可重推、隨時停止,重啟,這樣 Canal 的維護者無需關(guān)注底層的細(xì)節(jié),只需要通過頁面簡單配置一下即可。
源碼 Canal 系列的第一篇文章后有好幾個粉絲表示目前也在研究 Canal,由于筆者目前只能盡量保持周更,如果大家希望加快研究 Canal 的步伐,筆者有如下建議:
1、深入研究其四大核心組件,并帶著問題去研究,例如在學(xué)習(xí)元數(shù)據(jù)管理時是如何保證數(shù)據(jù)不丟失,重啟后又是如何定位位點的。
2、如果大家想更全局的去研究 Canal,我覺得除了閱讀 Canal 官方的設(shè)計手冊,還可以專門去看一下 CanalParameter 這個類,Canal 支持的所有配置屬性,并且都有相應(yīng)的注釋,關(guān)于 Canal 的所有一切,都可以從這里窺探出端倪,然后可以選擇感興趣的內(nèi)容加以繼續(xù)深入學(xué)習(xí)。
關(guān)于Canal Instance 設(shè)計理念與定制開發(fā)思路是什么就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,可以學(xué)到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。