TiCDC系列分享-01-简述产生背景及使用概况
\n> 原文來源： https://tidb.net/blog/70588c4c \n\n## 一、項目背景
如 PingCAP 官網 所述，TiCDC 的使用場景主要有 “數據庫災備” 及 “數據集成” 。熟悉 TiDB 周邊生態的愛好者一定知道 “TiDB Binlog” 這一與 TiCDC 功能相似的工具， 那么為什么要重復工作呢？
答案是 “TiDB Binlog” 無法存在以下(非全部)種種問題，對于 “TiDB Binlog” 還不熟悉的伙伴參考 TiDB Binlog 簡介 ：
1. “TiDB Binlog” 擴展性差，如：Drainer 存在 “單點” 、“性能” 問題，拆分 Drainer 無法保證 “數據行變更有序性”；
2. “TiDB Binlog” 性能低下，如：“TiDB Binlog” 僅支持單 kafka 單 partition 寫入，無法提高 kafka 吞吐量；
3. “TiDB Binlog” 通用型差，如：binlog 寫成文件需要使用 Reparo 解析 SQL 語句，不支持 Maxwell 等通用協議；
4. “TiDB Binlog” 同步痛點，如：binlog 寫到下游受限制多，如 Pump 的 gRPC message 超過限值 等等；
5. “TiDB Binlog” 可用性差，如：單點的 Drainer 一旦出現問題同步將中斷，不存在一定程度的自愈功能；
由此 TiCDC 應運而生，通過直接捕獲 TiKV Change Log ，將表作為拆分單元調度至各 Capture 中，并發向下游同步數據解決擴展性問題。可 kafka 多 partition 寫入，并支持 Maxwell、Canal 等多種通用協議，解決同步性能、生態通用性問題。當同步超時、 Capture 同步表數量不均、Capture 掛掉等情況時，TiCDC 存在調度機制及 At Least Once 保證冪等的數據完整性前提下，調度實現自愈合。
二、工具位置
首先，熟知 TiCDC 使用方法，必先明確其在 TiDB 生態工具所處的位置及作用。
1. 作用而言 ：數據庫如果是個只進不出的 “貔貅” ，那么必將被市場所拋棄，也就是所謂的 “數據孤島” ，TiCDC 兼顧同步性能、數據完整性，一致性、生態通用性，實現了數據從 "流入-> TiDB ->流出" 的閉環。此外，談性能如果拋棄了場景（不深入討論），那就是在耍流氓，沒有任何一個款產品能完勝所有場景，TiDB 同樣也有自己的舒適區、痛點區。 有了 TiCDC 之后，用戶可以輕松實現數據的流轉，把 TiDB 用在使用場景的舒適區。
2. 位置而言 ：TiCDC 介于 TiDB 與下游目的端之間，下游包含兼用 MySQL 通許協議的所有產品、平臺（如：TiDB、MySQL、RDS、三方云平臺等）。用戶還可基于通用消息隊列輸出協議自定義開發，現 TiCDC 支持的協議有：Open Protocol 、Canal-JSON 、 Canal 、Avro 、 Maxwell 等協議，有些協議僅部分支持，詳情參考 --> TiCDC 支持的協議指南 。
其次，TiCDC 幾乎囊括所有主流 “數據同步” 的使用場景，下圖便是 “MySQL --> TiDB --> Others” 的經典組合拳。至于其他協議的數據庫（Oracle、PG）如何流入 TiDB，等同于如何流入 MySQL，因為 TiDB 兼容 MySQL 通訊協議，一定存在較成熟的解決方案。
三、使用情況
注意：下述公司均通過 AskTUG 搜索相關文章得到，即：分享文章中有提及該公司正在使用 TICDC。下述公司僅是通過搜索手段可得知的公司，還有許多商業客戶要求不對外透露、或還未來得及透露。
3.1 小紅書
從 張億皓老師 在 【PingCAP Infra Meetup】No.131 TiCDC 的生態和社區建設 中分享可知，小紅書基于 TiCDC 在業務中進行內容審核、筆記標簽推薦、增長審計。實現如下圖，基于 "TiDB --> TiCDC --> Kafka --> Flink --> TiDB" 這樣一條鏈路實現與架構中其他數據源的聚合計算。
3.2 海爾智家
從 姚翔老師 在 【PingCAP Infra Meetup】No.131 TiCDC 的生態和社區建設 中分享可知，海爾智家基于 TICDC 在業務中進行搜索、推薦。將用戶數據、生活家信息數據基于 "TiDB --> TiCDC --> Kafka --> ES" 這樣一條鏈路實現 Kafka 日消費量在 300 萬左右的近實時搜索功能。從描述中可知截止 2019-09-19 分享時， TiCDC 在不涉及表數量、LOB 字段、網絡延時等細節情況下，同步能力邊界為：正常同步在 “毫秒” 級，抖動情況下在 “秒級”（10s 以內）。 此外，從 Github -- Question and Bug Reports 中可以看出 TiCDC 存在 mqSink flushes data synchronously,casing low performance 、 Poor incremental scan performance where they are frequent insertions 、 improve performance of syncer 等多個提升同步性能的 RoadMap，對于 TiCDC 的同步性能是一個持續優化的過程。
3.3 360
從 代曉磊老師 在 BLOG - TiCDC 應用場景解析 中分享可知，360 基于 TiCDC 實現并參與立項 增量數據抽取、同城雙集群熱備、流處理求 的需求。
四、使用方法
4.1 部署 TiCDC
下述測試環境搭建 TiCDC ，目的測試、學習 TiCDC 同步功能。 172.16.6.155:8300 及 172.16.6.196:8300 的 CDC 組件會在擴容后出現。
[tidb@Linux-Hostname ~]$ tiup cluster display tidb-testID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 172.16.6.155:9093 alertmanager 172.16.6.155 9093/9094 linux/x86_64 Up /home/data/tidb-home/data/alertmanager-9093 /home/data/tidb-deploy/alertmanager-9093 172.16.6.155:8300 cdc 172.16.6.155 8300 linux/x86_64 Up /data/deploy/install/data/cdc-8300 /home/data/tidb-deploy/cdc-8300 172.16.6.196:8300 cdc 172.16.6.196 8300 linux/x86_64 Up /data/deploy/install/data/cdc-8300 /home/data/tidb-deploy/cdc-8300 172.16.6.155:3000 grafana 172.16.6.155 3000 linux/x86_64 Up - /home/data/tidb-deploy/grafana-3000 172.16.6.155:2379 pd 172.16.6.155 2379/2380 linux/x86_64 Up|UI /home/data/tidb-home/data/pd-2379 /home/data/tidb-deploy/pd-2379 172.16.6.194:2379 pd 172.16.6.194 2379/2380 linux/x86_64 Up /home/data/tidb-home/data/pd-2379 /home/data/tidb-deploy/pd-2379 172.16.6.196:2379 pd 172.16.6.196 2379/2380 linux/x86_64 Up|L /home/data/tidb-home/data/pd-2379 /home/data/tidb-deploy/pd-2379 172.16.6.155:9090 prometheus 172.16.6.155 9090/12020 linux/x86_64 Up /home/data/tidb-home/data/prometheus-9090 /home/data/tidb-deploy/prometheus-9090 172.16.6.155:4000 tidb 172.16.6.155 4000/10080 linux/x86_64 Up - /home/data/tidb-deploy/tidb-4000 172.16.6.196:4000 tidb 172.16.6.196 4000/10080 linux/x86_64 Up - /home/data/tidb-deploy/tidb-4000 172.16.6.155:20160 tikv 172.16.6.155 20160/20180 linux/x86_64 Up /home/data/tidb-home/data/tikv-20160 /home/data/tidb-deploy/tikv-20160 172.16.6.194:20160 tikv 172.16.6.194 20160/20180 linux/x86_64 Up /home/data/tidb-home/data/tikv-20160 /home/data/tidb-deploy/tikv-20160 172.16.6.196:20160 tikv 172.16.6.196 20160/20180 linux/x86_64 Up /home/data/tidb-home/data/tikv-20160 /home/data/tidb-deploy/tikv-20160TiCDC 在 4.0.6 版本 GA，建議使用 4.0.6 及以后的版本 ，詳情參考 --> TiCDC 官方文檔 ，擴容步驟如下。
[tidb@Linux-Hostname ~]$ cat scale-out-cdc.yaml cdc_servers:- host: 172.16.6.155gc-ttl: 86400data_dir: /data/deploy/install/data/cdc-8300- host: 172.16.6.196gc-ttl: 86400data_dir: /data/deploy/install/data/cdc-8300[tidb@Linux-Hostname ~]$ tiup cluster scale-out tidb-test scale-out-cdc.yaml4.2 同步至 Kafka
由于本人之前沒接觸過 kafka ,本著熟悉 TiCDC 也要了解其周邊工具的目的，從 kafka 官網 進行了簡單入門，如有任何正確性問題可及時評論區交流。
簡單了解后，個人覺得 kafka 類似 GoLang 中的 Channel，區別在于提供了高性能的、分布式的、高可用的、彈性的、容錯的、安全的 “事件流平臺” 服務。 kafka 官網介紹其事件流式處理機制如下圖所示，Topic 作為分發消費的邏輯單元，Partition 作為最小存儲單元，以 Hash Key 或其他策略將 Event 劃分到多個 Partition 中，提供高吞吐性能。
下面簡單試用下 kafka，操作步驟如下，目的為從 kafka 中解析出 TiCDC 分發給 kafka 的消息，不深入研究 kafka 體系及調優。
# 安裝 Java 運行環境 [tidb@kafka1 ~]$ yum install java-1.8.0-openjdk.x86_64 [tidb@kafka1 ~]$ java -version openjdk version "1.8.0_322"# 依據 kafka quickstart 在 172.16.6.155、172.16.6.196 兩個 server 架起 kafka [tidb@kafka1 ~]$ wget https://dlcdn.apache.org/kafka/3.1.0/kafka_2.13-3.1g/kafka/3.1.0/kafka_2.13-3.1.0.tgz --no-check-certificate [tidb@kafka1 ~]$ tar -xzf kafka_2.13-3.1.0.tgz [tidb@kafka1 ~]$ cd kafka_2.13-3.1.0 [tidb@kafka1 ~]$ bin/zookeeper-server-start.sh config/zookeeper.properties [tidb@kafka1 ~]$ bin/kafka-server-start.sh config/server.properties# 創建 partition 為 2、topic-name 為 tidb-test 的 topic [tidb@kafka1 ~]$ bin/kafka-topics.sh --create --topic tidb-test \--bootstrap-server 172.16.6.155:9092,172.16.6.196:9092 \--partitions 2 Created topic quickstart-events.# 查看 topic-name 為 tidb-test 的 topic 的配置情況，可以看到 partition 為 2 [tidb@kafka1 ~]$ bin/kafka-topics.sh --describe --topic tidb-test \--bootstrap-server 172.16.6.155:9092,172.16.6.196:9092 Topic: tidb-test TopicId: OjM6FFrBQtqyEB4sVWmYCQ PartitionCount: 2 ReplicationFactor: 1 Configs: segment.bytes=1073741824Topic: tidb-test Partition: 0 Leader: 0 Replicas: 0 Isr: 0Topic: tidb-test Partition: 1 Leader: 0 Replicas: 0 Isr: 0# 創建 TiCDC 到 kafka 的 changefeed 同步,并復用手動創建的 tidb-test topic [tidb@kafka1 ~]$ tiup cdc cli changefeed create --pd=http://172.16.6.155:2379 \--sink-uri="kafka://172.16.6.155:9092/tidb-test?protocol=canal-json&kafka-version=2.4.0&partition-num=2&max-message-bytes=67108864&replication-factor=1" tiup is checking updates for component cdc ... Starting component `cdc`: /home/tidb/.tiup/components/cdc/v6.0.0/cdc /home/tidb/.tiup/components/cdc/v6.0.0/cdc cli changefeed create --pd=http://172.16.6.155:2379 --sink-uri=kafka://172.16.6.155:9092/tidb-test?protocol=canal-json&kafka-version=2.4.0&partition-num=2&max-message-bytes=67108864&replication-factor=1 [2022/05/12 16:37:09.667 +08:00] [WARN] [kafka.go:416] ["topic's `max.message.bytes` less than the `max-message-bytes`,use topic's `max.message.bytes` to initialize the Kafka producer"] [max.message.bytes=1048588] [max-message-bytes=67108864] [2022/05/12 16:37:09.667 +08:00] [WARN] [kafka.go:425] ["topic already exist, TiCDC will not create the topic"] [topic=tidb-test] [detail="{\"NumPartitions\":2,\"ReplicationFactor\":1,\"ReplicaAssignment\":{\"0\":[0],\"1\":[0]},\"ConfigEntries\":{\"segment.bytes\":\"1073741824\"}}"] Create changefeed successfully! ......# 利用 sysbench 向 jan.sbtest1 中插入 2 行數據 [tidb@kafka1 ~]$ sysbench oltp_read_write --mysql-host=127.0.0.1 \--mysql-port=4000 \--mysql-db=jan \--mysql-user=root \--mysql-password= \--table_size=2 \--tables=1 prepare# 從 kafka 中解析 TiDB 的數據變更如下 [tidb@kafka1 ~]$ bin/kafka-console-consumer.sh --topic tidb-test \--from-beginning --bootstrap-server 172.16.6.155:9092,172.16.6.196:9092 {"id":0,"database":"jan","table":"sbtest1","pkNames":["id"],"isDdl":false,"type":"INSERT","es":1652344970654,"ts":1652344977538,"sql":"","sqlType":{"c":1,"id":4,"k":4,"pad":1},"mysqlType":{"c":"char","id":"int","k":"int","pad":"char"},"data":[{"c":"83868641912-28773972837-60736120486-75162659906-27563526494-20381887404-41576422241-93426793964-56405065102-33518432330","id":"1","k":"1","pad":"67847967377-48000963322-62604785301-91415491898-96926520291"}],"old":null} {"id":0,"database":"jan","table":"sbtest1","pkNames":["id"],"isDdl":false,"type":"INSERT","es":1652344970654,"ts":1652344977538,"sql":"","sqlType":{"c":1,"id":4,"k":4,"pad":1},"mysqlType":{"c":"char","id":"int","k":"int","pad":"char"},"data":[{"c":"38014276128-25250245652-62722561801-27818678124-24890218270-18312424692-92565570600-36243745486-21199862476-38576014630","id":"2","k":"2","pad":"23183251411-36241541236-31706421314-92007079971-60663066966"}],"old":null} {"id":0,"database":"jan","table":"","pkNames":null,"isDdl":true,"type":"QUERY","es":1652344966953,"ts":1652344969305,"sql":"CREATE DATABASE `jan`","sqlType":null,"mysqlType":null,"data":null,"old":null} {"id":0,"database":"jan","table":"sbtest1","pkNames":null,"isDdl":true,"type":"CREATE","es":1652344970604,"ts":1652344975305,"sql":"CREATE TABLE `sbtest1` (`id` INT NOT NULL AUTO_INCREMENT,`k` INT DEFAULT _UTF8MB4'0' NOT NULL,`c` CHAR(120) DEFAULT _UTF8MB4'' NOT NULL,`pad` CHAR(60) DEFAULT _UTF8MB4'' NOT NULL,PRIMARY KEY(`id`)) ENGINE = innodb","sqlType":null,"mysqlType":null,"data":null,"old":null} {"id":0,"database":"jan","table":"sbtest1","pkNames":null,"isDdl":true,"type":"CINDEX","es":1652344973455,"ts":1652344978504,"sql":"CREATE INDEX `k_1` ON `sbtest1` (`k`)","sqlType":null,"mysqlType":null,"data":null,"old":null}# 實驗結束清理 172.16.6.155、172.16.6.196 兩個 server 架起 kafka 環境 # 首先 ctrl + c 關閉所有終端啟動的前臺進程 [tidb@kafka1 ~]$ rm -rf /tmp/kafka-logs /tmp/zookeeper4.3 同步至 MySQL
在 172.16.6.155:3306 本地裝個 MySQL，指定相關參數后便可創建訂閱任務，id 為 simple-replication-task，在 Grafana 監控面板中可觀察到同步進度。MySQL 對于 DBA 講一定是較為熟悉的工具，因此驗證同步等步驟便不贅述。
[tidb@Linux-Hostname ~]$ tiup cdc cli changefeed create --pd=http://172.16.6.155:2379 \--sink-uri="mysql://jan:123123@172.16.6.155:3306/?time-zone=&worker-count=16&max-txn-row=5000" \--changefeed-id="simple-replication-task" \--sort-engine="unified" \--config=changefeed.toml tiup is checking updates for component cdc ... Starting component `cdc`: /home/tidb/.tiup/components/cdc/v6.0.0/cdc /home/tidb/.tiup/components/cdc/v6.0.0/cdc cli changefeed create --pd=http://172.16.6.155:2379 --sink-uri=mysql://jan:123123@172.16.6.155:3306/?time-zone=&worker-count=16&max-txn-row=5000 --changefeed-id=simple-replication-task --sort-engine=unified --config=changefeed.toml [2022/04/12 16:58:40.954 +08:00] [WARN] [mysql_params.go:143] ["max-txn-row too large"] [original=5000] [override=2048] Create changefeed successfully! ......五、引用文章
1. 【PingCAP Infra Meetup】No.131 Why and how we build TiCDC
2. 【PingCAP Infra Meetup】No.131 TiCDC 的生態和社區建設
3. 官方文檔 -- TiCDC
4. 官方文檔 -- TiDB Binlog
5. 官方 FAQ -- Pump 的 gRPC message 超過限值
6. Github Design Doc -- TiCDC 支持的消息隊列輸出協議指南
7. Github Question and Bug Reports -- TiCDC 提升性能規劃路徑
8. AskTUG Blog -- 代曉磊 TiCDC 應用場景解析
9. 官方文檔 -- Kafka
總結
以上是生活随笔為你收集整理的TiCDC系列分享-01-简述产生背景及使用概况的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： php结合HTML表格输出乘法表
- 下一篇： MIT线性代数1806(35) 总复习