一、CDC概述

1.1 什么是CDC

CDC 的全稱是 Change Data Capture ，在廣義的概念上，只要能捕獲數(shù)據(jù)變更的技術(shù)，我們都可以稱為 CDC 。我們通常所描述的CDC 技術(shù)主要是指面向數(shù)據(jù)庫的變更，是一種用于捕獲數(shù)據(jù)庫中數(shù)據(jù)變更的技術(shù)。

1.2 應(yīng)用場景

• 數(shù)據(jù)同步，用于備份，容災(zāi)

• 數(shù)據(jù)分發(fā)，一個數(shù)據(jù)源分發(fā)給多個下游系統(tǒng)

• 數(shù)據(jù)采集，面向數(shù)據(jù)倉庫/數(shù)據(jù)湖的 ETL 數(shù)據(jù)集成，是非常重要的數(shù)據(jù)源

1.3 主要實(shí)現(xiàn)機(jī)制分類

• 基于查詢的 CDC

• 基于日志的 CDC

差異點(diǎn)對比：

總結(jié)：

經(jīng)過以上對比，我們可以發(fā)現(xiàn)基于日志的 CDC 有以下幾種優(yōu)勢：

• 能夠捕獲所有數(shù)據(jù)的變化，捕獲完整的變更記錄。在異地容災(zāi)，數(shù)據(jù)備份等場景中得到廣泛應(yīng)用，如果是基于查詢的 CDC 有可能導(dǎo)致兩次查詢的中間一部分?jǐn)?shù)據(jù)丟失

• 每次 DML 操作均有記錄無需像查詢 CDC 這樣發(fā)起全表掃描進(jìn)行過濾，擁有更高的效率和性能，具有低延遲，不增加數(shù)據(jù)庫負(fù)載的優(yōu)勢

• 無需入侵業(yè)務(wù)，業(yè)務(wù)解耦，無需更改業(yè)務(wù)模型

• 捕獲刪除事件和捕獲舊記錄的狀態(tài)，在查詢 CDC 中，周期的查詢無法感知中間數(shù)據(jù)是否刪除

二、CDC?工具介紹

簡單了解了CDC的概念以及一些基本的CDC工具之后，下面我們就針對個別CDC工具來進(jìn)行詳細(xì)介紹，以便幫助大家了解下CDC的具體工作原理。

2.1 canal

Canal 是用 Java 開發(fā)的基于數(shù)據(jù)庫增量日志解析，提供增量數(shù)據(jù)訂閱&消費(fèi)的中間件。

舉個例子：假設(shè)我們有一個需要同步數(shù)據(jù)的數(shù)據(jù)庫product_source，還有一個用來存儲product_source中數(shù)據(jù)的數(shù)據(jù)庫product_sink，若product_source中有10條數(shù)據(jù)，那么此時我們就可以啟動canal，將product_source中后續(xù)更新的數(shù)據(jù)同步到product_sink這個數(shù)據(jù)庫中。不過，這同時也體現(xiàn)出了canal的一個缺點(diǎn)——不支持?jǐn)?shù)據(jù)的全量同步，也就是說之前的10條數(shù)據(jù)是無法通過canal同步過去的。

目前，Canal 主要支持了 MySQL 的 Binlog 解析。

可能有些同學(xué)對于MySQL的Binlog不太熟悉，這里簡單介紹一下：

Binlog概述：

MySQL 的二進(jìn)制日志記錄了所有的 DDL 和 DML(除了數(shù)據(jù)查詢語句)語句，以事件形式記錄，還包含語句執(zhí)行時所消耗的時間，MySQL 的二進(jìn)制日志是事務(wù)安全型的。

一般來說開啟二進(jìn)制日志大概會有 1%的性能損耗。二進(jìn)制有兩個最重要的使用場景:

其一：MySQL Replication 在 Master 端開啟 Binlog，Master 把它的二進(jìn)制日志傳遞給 Slaves，來達(dá)到 Master-Slave 數(shù)據(jù)一致的目的。

其二：自然就是數(shù)據(jù)恢復(fù)了，通過使用 MySQL Binlog 來使數(shù)據(jù)恢復(fù)。

二進(jìn)制日志包括兩類文件：二進(jìn)制日志索引文件（文件名后綴為.index），用于記錄所有的二進(jìn)制文件；二進(jìn)制日志文件（文件名后綴為.00000*），用于記錄數(shù)據(jù)庫所有的 DDL 和 DML(除了數(shù)據(jù)查詢語句)語句事件。

Binlog分類：

MySQL Binlog 的格式有三種，分別是 STATEMENT，MIXED和ROW。在配置文件中可以選擇配置：

binlog_format= statement|mixed|row。?

三種格式的區(qū)別：

1）statement：語句級，binlog 會記錄每次執(zhí)行寫操作的語句。相較于 row 模式更節(jié)省空間，但是可能會產(chǎn)生不一致性，比如“update tt set create_date=now()”，如果用 binlog 日志進(jìn)行恢復(fù)，由于執(zhí)行時間不同可能產(chǎn)生的數(shù)據(jù)就不同。

優(yōu)點(diǎn)：節(jié)省空間。

缺點(diǎn)：有可能造成數(shù)據(jù)不一致。

2）row：行級， binlog 會記錄每次操作后每行記錄的變化。

優(yōu)點(diǎn)：保持?jǐn)?shù)據(jù)的絕對一致性。因?yàn)椴还?sql 是什么，引用了什么函數(shù)，他只記錄執(zhí)行后的效果。

缺點(diǎn)：占用較大空間。

3）mixed：statement 的升級版，一定程度上解決了因?yàn)橐恍┣闆r而造成的 statement模式不一致問題，默認(rèn)還是 statement，但在某些情況下譬如：當(dāng)函數(shù)中包含 UUID() 時；包含AUTO_INCREMENT 字段的表被更新時；執(zhí)行 INSERT DELAYED 語句時；用 UDF 時，會按照ROW 的方式進(jìn)行處理。

優(yōu)點(diǎn)：節(jié)省空間，同時兼顧了一定的一致性。

缺點(diǎn)：還有極個別情況依舊會造成不一致，另外 statement 和 mixed 對于那種需要對binlog進(jìn)行監(jiān)控的情況來說都不方便。

Canal工作原理

MySQL主備復(fù)制原理：?

?

• MySQL master 將數(shù)據(jù)變更寫入二進(jìn)制日志( binary log，其中的記錄叫做二進(jìn)制日志事件binary log events，可以通過 show binlog events 進(jìn)行查看)

• MySQL slave 將 master 的 binary log events 拷貝到它的中繼日志(relay log)里面

• MySQL slave 重放 relay log 中的事件，將數(shù)據(jù)變更反映成它自己的數(shù)據(jù)

canal 工作原理：

• canal 模擬 MySQL slave 的交互協(xié)議，把自己偽裝成?MySQL slave ，向 MySQL master 發(fā)送dump 協(xié)議

• MySQL master 收到 dump 請求，開始推送 binary log 給 slave (即 canal )

• canal 解析 binary log 對象(原始為 byte 流)

思路梳理：

現(xiàn)在，我們知道了Mysql Binlog的基本情況：記錄了所有的 DDL 和 DML(除了數(shù)據(jù)查詢語句)語句。那么當(dāng)canal獲取到這些DDL和DML語句時，就需要針對這些語句進(jìn)行解析，然后可以按照配置過濾掉不需要的數(shù)據(jù)，最后將數(shù)據(jù)分發(fā)到下游，完成同步。那么我們就帶著這個思路來了解下canal的架構(gòu)。

??

canal架構(gòu)：

• server 代表一個 canal 運(yùn)行實(shí)例，對應(yīng)一個 jvm。既然有server，那么自然就有client。server端主要負(fù)責(zé)同步mysql消息，client負(fù)責(zé)訪問server端消費(fèi)消息。

• instance 對應(yīng)一個數(shù)據(jù)隊(duì)列 （1個 canal server 對應(yīng) 1..n 個 instance )

• instance 下的子模塊

–?eventParser: 數(shù)據(jù)源接入，模擬 slave 協(xié)議和 master 進(jìn)行交互，協(xié)議解析

–?eventSink: Parser 和 Store 鏈接器，進(jìn)行數(shù)據(jù)過濾，加工和分發(fā)的工作

–?eventStore: 數(shù)據(jù)存儲

–?metaManager: 增量訂閱 & 消費(fèi)信息管理器

Canal的Server端本身根據(jù)配置啟動了很多個Instance對象，所謂的Instance對象就是模擬的數(shù)據(jù)庫slave和master進(jìn)行連接，換句話說就是假設(shè)canal同時成為N個數(shù)據(jù)庫的slave，那么就會有N個Instance實(shí)例。

同步的數(shù)據(jù)流是按照eventParser->eventSink->eventStore進(jìn)行傳輸?shù)摹?/p>

eventParser：

最基本的組件，類似于mysql從庫的dump線程，負(fù)責(zé)從master中獲取bin_log并解析

從圖中可以看出，eventParser負(fù)責(zé)記錄binlog解析位置、偽裝slave端獲取binlog、解析binlog并傳遞。

eventSink ：

使用設(shè)置的filter對bin log進(jìn)行過濾、路由/分發(fā)等。?

eventStore ：

用來存儲filter過濾后的數(shù)據(jù)，目前實(shí)現(xiàn)了 memory 模式，支持按照內(nèi)存大小和內(nèi)存記錄數(shù)進(jìn)行存儲大小限制。

canal整體架構(gòu)：

?

總結(jié)：

canal server代表一個canal運(yùn)行實(shí)例，該實(shí)例可以同時監(jiān)控多個數(shù)據(jù)庫的binlog，那么想要同時監(jiān)控多個數(shù)據(jù)庫的binlog，就需要開啟多個instance實(shí)例，數(shù)據(jù)庫與instance一般是一一對應(yīng)的關(guān)系。那么我們可以理解為一個instance就是用來同步某個數(shù)據(jù)庫的一條龍服務(wù)：即需要包含獲取該數(shù)據(jù)庫的binlog、解析binlog、對binlog進(jìn)行過濾分發(fā)，將處理完的數(shù)據(jù)暫時存儲，等待消費(fèi)端獲取數(shù)據(jù)，同時需要記錄自己的binlog日志解析的位置，所以每個instance實(shí)例又包含parser、sink、store以及metamanager服務(wù)。

注意：如果沒有client消費(fèi)數(shù)據(jù)，server是不會從mysql中去獲取日志的。同樣的，由于event store是將數(shù)據(jù)存儲在內(nèi)存隊(duì)列中的，當(dāng)隊(duì)列滿了之后，server就會阻塞從而無法繼續(xù)獲取binlog。

Canal特性：

1. 支持所有平臺。

2. 支持細(xì)粒度的系統(tǒng)監(jiān)控，由Prometheus提供支持。

3. 支持通過GTID等不同方式解析和訂閱MySQL binlog。

4. 支持高性能、實(shí)時的數(shù)據(jù)同步。

5. Canal Server 和 Canal Client 都支持 HA/Scalability。

6. 支持docker。

了解canal的工作原理后，其實(shí)應(yīng)該對所有的CDC工具的基本實(shí)現(xiàn)有了初步的了解。譬如第一點(diǎn)：如果獲取源數(shù)據(jù)庫的日志變更信息，譬如mysql是將這些信息保存在binlog，但是sqlserver、oracle等并沒有binlog的概念，但是有類似的東西，所以基于日志的CDC工具必然需要支持獲取這些日志并解析（類似于canal偽裝成slave去獲取binlog）。然后將解析的數(shù)據(jù)經(jīng)過轉(zhuǎn)換分發(fā)，最后供給下游消費(fèi)。差異點(diǎn)無非是支持的功能可能各不相同，比如增量同步、全量同步、全量+增量同步模式的支持，再比如數(shù)據(jù)轉(zhuǎn)換方面的支持，有些工具可以針對表字段進(jìn)行聚合、計(jì)算等操作之后再同步到目標(biāo)表。

本期主要依據(jù)canal簡單介紹CDC工具的大致工作原理，具體業(yè)務(wù)選擇還需要根據(jù)具體的業(yè)務(wù)目標(biāo)進(jìn)行調(diào)研和考察。

本期主要內(nèi)容就先到這里，感謝閱讀。

* 部分素材來源于網(wǎng)絡(luò)，版權(quán)歸原作者所有，如有侵權(quán)請聯(lián)系刪除。文章來源地址http://www.zghlxwxcb.cn/news/detail-427295.html

到了這里，關(guān)于CDC工具之Canal的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！