@
[Mysql數據實時增量同步之CDC工具—Canal、mysql_stream、go-mysql-transfer、Maxwell：https://blog.csdn.net/weixin_42526326/article/details/121148721
什么是CDC？
CDC(Change Data Capture)是變更數據獲取的簡稱。可以基於增量日志，以極低的侵入性來完成增量數據捕獲的工作。核心思想是，監測並捕獲數據庫的變動（包括數據或數據表的插入、更新以及刪除等），將這些變更按發生的順序完整記錄下來，寫入到消息中間件中以供其他服務進行訂閱及消費。
簡單來講：CDC是指從源數據庫捕獲到數據和數據結構(也稱為模式)的增量變更，近乎實時地將這些變更，傳播到其他數據庫或應用程序之處。
通過這種方式，CDC能夠向數據倉庫提供高效、低延遲的數據傳輸，以便信息被及時轉換並交付給專供分析的應用程序。
與批量復制相比，變更數據的捕獲通常具有如下三項基本優勢：
- CDC通過僅發送增量的變更，來降低通過網絡傳輸數據的成本。
- CDC可以幫助用戶根據最新的數據做出更快、更准確的決策。例如，CDC會將事務直接傳輸到專供分析的應用上。
- CDC最大限度地減少了對於生產環境網絡流量的干擾。
CDC工具對比
| 特色 | Canal | mysql_stream | go-mysql-transfer | Maxwell |
|---|---|---|---|---|
| 開發語言 | Java | Python | Golang | Java |
| 高可用 | 支持 | 支持 | 支持 | 支持 |
| 接收端 | 編碼定制 | Kafka等(MQ) | Redis、MongoDB、Elasticsearch、RabbitMQ、Kafka、RocketMQ、HTTP API 等 | Kafka，Kinesis、RabbitMQ、Redis、Google Cloud Pub/Sub、文件等 |
| 全量數據初始化 | 不支持 | 支持 | 支持 | 支持 |
| 數據格式 | 編碼定制 | Json（固定格式） | Json（規則配置) 模板語法 Lua腳本 | JSON |
| 性能(4-8TPS) |
實現原理：
1、go-mysql-transfer將自己偽裝成MySQL的Slave，
2、向Master發送dump協議獲取binlog，解析binlog並生成消息
3、將生成的消息實時、批量發送給接收端
Mysql binlog 講解：
MySQL的二進制日志可以說MySQL最重要的日志了，它記錄了所有的DDL和DML(除了數據查詢語句)語句，
以事件形式記錄，還包含語句所執行的消耗的時間，MySQL的二進制日志是事務安全型的。
一般來說開啟二進制日志大概會有1%的性能損耗。
二進制日志兩個最重要的使用場景:
- MySQL Replication在Master端開啟binlog，Master把它的二進制日志傳遞給slaves來達到master-slave數據一致的目的。
- 數據恢復，通過使用mysqlbinlog工具來使恢復數據。
二進制日志包括兩類文件：
-
二進制日志索引文件（文件名后綴為.index）用於記錄所有的二進制文件
-
二進制日志文件（文件名后綴為.00000*）記錄數據庫所有的DDL和DML(除了數據查詢語句)語句事件。
binlog文件的滾動：
- 達到了滾動的大小
- mysql服務停止
mysql binlog的三種格式
在配置文件中可以選擇配置 binlog_format= statement|mixed|row
-
ROW 模式（一般就用它）
日志會記錄每一行數據被修改的形式，不會記錄執行 SQL 語句的上下文相關信息，只記錄要修改的數據，哪條數據被修改了，修改成了什么樣子，只有 value，不會有 SQL 多表關聯的情況。
優點：它僅僅只需要記錄哪條數據被修改了，修改成什么樣子了，所以它的日志內容會非常清楚地記錄下每一行數據修改的細節，非常容易理解。
缺點：ROW 模式下，特別是數據添加的情況下，所有執行的語句都會記錄到日志中，都將以每行記錄的修改來記錄，這樣會產生大量的日志內容。
-
STATEMENT 模式
每條會修改數據的 SQL 語句都會被記錄下來。
缺點：由於它是記錄的執行語句，所以，為了讓這些語句在 slave 端也能正確執行，那他還必須記錄每條語句在執行過程中的一些相關信息，也就是上下文信息，以保證所有語句在 slave 端被執行的時候能夠得到和在 master 端執行時候相同的結果。
但目前例如 step()函數在有些版本中就不能被正確復制，在存儲過程中使用了 last-insert-id()函數，可能會使 slave 和 master 上得到不一致的 id，就是會出現數據不一致的情況，ROW 模式下就沒有。
-
MIXED 模式
以上兩種模式都使用。
常見的數據采集工具（相關知識）：
DataX、Flume、Canal、Sqoop、LogStash
DataX (處理離線數據)
DataX 是阿里巴巴開源的一個異構數據源離線同步工具，異構數據源離線同步指的是將源端數據同步到目的端，但是端與端的數據源類型種類繁多，在沒有 DataX 之前，端與端的鏈路將組成一個復雜的網狀結構，非常零散無法把同步核心邏輯抽象出來。
為了解決異構數據源同步問題，DataX 將復雜的網狀的同步鏈路變成了星型數據鏈路，DataX 作為中間傳輸載體負責連接各種數據源。
所以，當需要接入一個新的數據源的時候，只需要將此數據源對接到 DataX，就可以跟已有的數據源做到無縫數據同步。
DataX本身作為離線數據同步框架，采用Framework+plugin架構構建。將數據源讀取和寫入抽象成為Reader/Writer插件，納入到整個同步框架中。
- Reader: 它為數據采集模塊，負責采集數據源的數據，將數據發送給Framework。
- Writer: 它為數據寫入模塊，負責不斷向Framework取數據，並將數據寫入到目的端。
- Framework：它用於連接Reader和Writer，作為兩者的數據傳輸通道，並處理緩沖、並發、數據轉換等問題。
核心模塊介紹：
- DataX完成單個數據同步的作業，我們把它稱之為Job，DataX接收到一個Job之后，將啟動一個進程來完成整個作業同步過程。
- DataX Job啟動后，會根據不同的源端切分策略，將Job切分成多個小的Task(子任務)，以便於並發執行。
- 切分多個Task之后，DataX Job會調用Scheduler模塊，根據配置的並發數據量，將拆分成的Task重新組合，組裝成TaskGroup(任務組)。每一個TaskGroup負責以一定的並發運行完畢分配好的所有Task，默認單個任務組的並發數量為5。
- 每一個Task都由TaskGroup負責啟動，Task啟動后，會固定啟動Reader->Channel->Writer的線程來完成任務同步工作。
- DataX作業運行完成之后，Job監控並等待多個TaskGroup模塊任務完成，等待所有TaskGroup任務完成后Job成功退出。否則，異常退出。
Flume（處理實時數據）
Flume主要應用的場景是同步日志數據，主要包含三個組件：Source、Channel、Sink。
Flume最大的優點就是官網提供了豐富的Source、Channel、Sink，根據不同的業務需求，我們可以在官網查找相關配置。另外，Flume還提供了自定義這些組件的接口。
Logstash（處理離線數據）
Logstash就是一根具備實時數據傳輸能力的管道，負責將數據信息從管道的輸入端傳輸到管道的輸出端；與此同時這根管道還可以讓你根據自己的需求在中間加上過濾網，Logstash提供了很多功能強大的過濾網來滿足各種應用場景。
Logstash是由JRuby編寫，使用基於消息的簡單架構，在JVM上運行。在管道內的數據流稱之為event，它分為inputs階段、filters階段、outputs階段。
Sqoop（處理離線數據）
Sqoop是Hadoop和關系型數據庫之間傳送數據的一種工具，它是用來從關系型數據庫如MySQL到Hadoop的HDFS從Hadoop文件系統導出數據到關系型數據庫。Sqoop底層用的還是MapReducer，用的時候一定要注意數據傾斜。
注:sqoop不是CDC工具 sqoop是基於查詢的全量數據捕獲.
參考：