1. Flink CDC 概述：从数据同步说起
大家好，我是你们的老朋友。今天咱们正式开讲《Flink CDC 实时同步技术详解》的第一章。
先聊聊我自己的经历。几年前我在一家电商公司做数据架构，每天最头疼的事就是怎么把 MySQL 里的订单数据实时同步到数仓。那时候的方案，要么是定时跑批，要么是自己写 Binlog 客户端。嗯，都不太优雅。直到后来接触了 CDC 技术，才算是找到了正解。
1.1 什么是 CDC？
CDC，全称 Change Data Capture，中文叫「变更数据捕获」。说白了，就是监听数据库的变化，然后把新增、修改、删除的操作实时抓取出来。
你想想看，传统的数据同步方式是什么？定时跑个 Job，全量拉一遍。数据量小还行，一旦上了千万级，延迟高、压力大，根本扛不住。CDC 的思路完全不同——它只关注变化的数据，而不是全量扫描。
核心思想：CDC 把数据库的变更日志（比如 MySQL 的 Binlog、PostgreSQL 的 WAL）作为数据源，实时捕获每一行数据的 INSERT、UPDATE、DELETE 操作，然后推送给下游系统。
CDC 有两种常见的实现模式：
- 基于查询的 CDC：定期轮询数据库，通过时间戳或版本号判断哪些数据变了。简单但延迟高，对数据库有压力。
- 基于日志的 CDC：直接读取数据库的事务日志。实时性好，对业务库几乎无侵入。这也是目前主流的方式。
我个人习惯用基于日志的方式。原因很简单——不打扰业务。你想想，生产环境的数据库，谁敢随便加轮询？
1.2 CDC 技术选型对比
市面上 CDC 的工具不少，但真正能打的就那几个。我挑三个最常用的来对比：Debezium、Canal 和 Flink CDC。
| 对比维度 | Debezium | Canal | Flink CDC |
|---|---|---|---|
| 底层原理 | 基于 Kafka Connect，读取 Binlog/WAL | 模拟 MySQL Slave，解析 Binlog | 基于 Debezium 内核，深度集成 Flink |
| 支持的数据库 | MySQL、PostgreSQL、MongoDB、Oracle 等 | 仅 MySQL（含 MariaDB） | MySQL、PostgreSQL、Oracle、MongoDB、SqlServer 等 |
| 数据输出 | Kafka 为主，可自定义 Sink | Kafka、RocketMQ、自定义 | Flink 的 DataStream/Table API，输出灵活 |
| 断点续传 | 支持（基于 Offset） | 支持（基于 Position） | 支持（基于 Flink Checkpoint） |
| 全量+增量 | 需手动触发 Snapshot | 需额外开发 | 原生支持，自动切换 |
| 学习成本 | 中等（需理解 Kafka Connect） | 较低（专注 MySQL） | 中等（需 Flink 基础） |
我来逐个说说我的看法。
Debezium
Debezium 是个老牌选手，基于 Kafka Connect 架构。它在数据一致性方面做得很好，支持多种数据库。但有个问题——它把数据先写到 Kafka，然后你再从 Kafka 消费。多了一层，延迟和运维成本都上去了。我在项目中用过一次，Kafka 集群挂了，整个链路都断了，排查起来挺费劲。
Canal
Canal 是阿里巴巴开源的，专为 MySQL 设计。它模拟 MySQL Slave 的交互协议，直接解析 Binlog。性能不错，部署也简单。但缺点很明显——只支持 MySQL。如果你的技术栈里还有 PostgreSQL 或 Oracle，那就得另想办法了。
Flink CDC
Flink CDC 是我现在的主力工具。它底层封装了 Debezium，但把数据直接接入 Flink 的 DataStream 或 Table API。这意味着什么？你不需要中间件，不需要 Kafka，Flink 自己就能搞定一切。而且它原生支持全量+增量的一体化同步，自动切换，不用你操心。
我的建议：如果你的团队已经有 Flink 生态，直接上 Flink CDC。如果只是简单的 MySQL 同步，Canal 也够用。但如果你需要多数据库支持、复杂的数据加工，Flink CDC 是更优解。
1.3 Flink CDC 核心优势
Flink CDC 到底强在哪？我总结了四点。
- 全量+增量一体化：传统 CDC 工具，全量同步和增量同步是分开的。你得先跑个全量，再切到增量，中间还要保证数据不丢不重。Flink CDC 内置了 Snapshot 机制，启动时自动做全量，完成后无缝切换到增量。我在做某金融项目时，一张表 2 亿数据，全量+增量切换零误差，这个体验确实好。
- Exactly-Once 语义：基于 Flink 的 Checkpoint 机制，Flink CDC 能保证数据不丢不重。你想想，金融场景下，少一条数据可能就是几十万的损失。这个能力是 Canal 和 Debezium 单独使用时很难做到的。
- 丰富的下游支持：数据到了 Flink 里，你想怎么处理都行。可以写 Kafka、写 HBase、写 ClickHouse，甚至直接做实时 ETL。Flink 的 DataStream API 和 SQL 都能用，灵活性极高。
- 动态表与 Changelog 流：Flink CDC 把数据库的变更抽象成 Changelog 流（INSERT、UPDATE、DELETE），天然适配 Flink 的动态表模型。你可以直接用 SQL 做 Join、Aggregation，就像操作普通表一样。
避坑提醒：我曾经在一个项目中，直接用 Flink CDC 同步 MySQL 到 Kafka，结果发现 Binlog 的格式没配好（MySQL 的 binlog_row_image 没设成 FULL），导致 UPDATE 事件只传了主键和变更列，其他列全是 NULL。嗯，这个坑我踩过，大家记得提前检查 MySQL 配置。
1.4 应用场景
Flink CDC 能用在哪些地方？我列几个典型的。
- 实时数仓：把业务库的数据实时同步到数仓（比如 ClickHouse、Doris），替代传统的 T+1 离线同步。
- 缓存刷新：数据库变了，自动更新 Redis 或本地缓存，保证缓存与数据库一致。
- 微服务间数据同步：多个微服务共享同一份数据，通过 CDC 实现最终一致性。
- 数据迁移与备份：跨数据库、跨机房的数据实时迁移，Flink CDC 能保证数据不丢。
- 实时 ETL：对 CDC 数据进行清洗、转换、聚合，然后写入目标系统。
说白了，只要你的业务需要「数据库变了，下游立刻知道」，Flink CDC 就是你的好帮手。
1.5 核心架构图
下面这张图是我画的 Flink CDC 核心架构。它展示了从数据源到 Flink 再到下游的完整链路。
从图里你能看到，Flink CDC 处于中间层，它把不同数据源的变更日志统一成 Changelog 流，然后交给 Flink 做处理。下游可以是 Kafka、ClickHouse、HBase 等。整个过程不需要额外的消息队列，Flink 自己就能搞定。
1.6 本章小结
这一章我们聊了 CDC 的基本概念，对比了 Debezium、Canal 和 Flink CDC 的差异，也分析了 Flink CDC 的核心优势和应用场景。我个人觉得，Flink CDC 最大的价值在于「一体化」——全量增量一体化、数据加工一体化、状态管理一体化。它让实时数据同步这件事变得简单了很多。