2、Flink CDC架构原理：整体架构、SourceFunction、无锁算法与Chunk分裂、Checkpoint与Exactly-Once

好，咱们进入第二章。这一章我打算把Flink CDC的骨架给你拆开看看。说白了，就是搞清楚它到底是怎么把数据库的变更日志，一条不落地同步到下游的。

很多同学一开始接触CDC，觉得无非就是“监听binlog，然后发到Kafka”。但实际生产环境远没那么简单——数据量大了怎么办？表结构变了怎么办？重启之后怎么保证数据不丢不重？这些问题的答案，都藏在Flink CDC的架构设计里。

2.1 Flink CDC整体架构：一条数据从源头到终点的旅程

我们先从宏观上看一下Flink CDC的架构。我个人习惯把它分成三层：

• Source Connector层：负责对接各种数据源，比如MySQL、PostgreSQL、MongoDB。这一层做的事情很纯粹——把数据库的日志（binlog、WAL等）转换成Flink能识别的SourceEvent。
• Chunk分裂与分配层：这是Flink CDC 2.0+版本的核心改进。它把一张大表拆成多个小Chunk，然后分配给不同的TaskManager并行读取。嗯，这里要注意，Chunk分裂不是随机的，它需要基于表的主键或唯一索引来做。
• Checkpoint与状态管理层：负责记录读取进度。一旦任务失败，可以从最近一次Checkpoint恢复，保证Exactly-Once语义。

我画了一张架构图，你可以对照着看：

2.2 SourceFunction原理：从数据库日志到Flink数据流

SourceFunction是Flink CDC的“翻译官”。它的任务是把数据库底层的日志格式，翻译成Flink能处理的DataStream。

以MySQL为例，SourceFunction内部做了这么几件事：

1. 建立连接：通过JDBC连接到MySQL，同时启动一个Binlog监听客户端（通常是基于Canal或Debezium）。
2. 解析Binlog事件：Binlog里的每一行变更（INSERT/UPDATE/DELETE），都会被解析成一个SourceRecord。SourceRecord里包含了库名、表名、操作类型、变更前后的数据。
3. 反序列化：SourceRecord再经过反序列化器（Deserialization），变成Flink的RowData或JSON格式。
4. 发射数据：最终通过SourceFunction的collect()方法，把数据发射到下游算子。

我记得有一次排查线上问题，发现SourceFunction在解析Binlog时，遇到ALTER TABLE语句会直接报错。后来查了源码才知道，Debezium默认的EventDeserializationExceptionHandler会抛出异常。解决办法是自定义一个错误处理器，把DDL事件跳过或记录到日志里。

2.3 无锁算法与Chunk分裂机制：并行读取的核心秘密

好，接下来是这一章的重头戏——无锁算法和Chunk分裂。为什么需要这个？你想想看，如果一张表有1亿条数据，单线程读取要多久？就算每秒读1万条，也得将近3个小时。这显然不现实。

Flink CDC 2.0+的做法是：把一张大表拆成多个小Chunk，然后并行读取。但这里有个关键问题——拆的时候，数据库还在写入，怎么保证Chunk之间的数据不重复、不遗漏？

答案就是无锁算法。它的核心思想是：

• 先记录一个全局的低水位线（Low Watermark）：比如MySQL的Binlog Position或GTID。
• 然后并行读取各个Chunk：每个Chunk基于主键范围（比如ID 1-10000、10001-20000）读取全量数据。
• 再记录一个全局的高水位线（High Watermark）：所有Chunk读取完成后，记录当前的Binlog Position。
• 最后补读增量数据：从低水位线到高水位线之间的Binlog变更，再读取一遍，并跟Chunk数据做去重。

这个过程不需要对数据库加锁，所以叫“无锁算法”。

Chunk分裂的具体策略是这样的：

分裂依据	适用场景	优点	缺点
主键范围（如ID）	有自增主键的表	分裂均匀，容易并行	主键不连续时会有空洞
唯一索引	没有主键但有唯一索引的表	可以替代主键	索引值分布可能不均匀
自定义分片列	没有主键也没有唯一索引的表	灵活	需要用户手动指定，容易出错

我个人建议，在设计表结构时，尽量给每张表都加上自增主键。这不仅能提升CDC的并行读取效率，还能避免很多奇奇怪怪的问题。

2.4 Checkpoint与Exactly-Once语义：数据不丢不重的保障

最后，我们聊聊Exactly-Once。这是流处理中最难实现的目标之一。Flink CDC是怎么做到的？

核心机制就是Checkpoint。Flink的Checkpoint会定期保存每个算子的状态。对于CDC Source来说，状态就是“当前已经读取到的Binlog Position”。

具体流程是这样的：

1. Checkpoint触发：JobManager向SourceFunction发送一个Checkpoint Barrier。
2. SourceFunction暂停发射数据：但注意，它不会停止读取Binlog，只是把新读取的数据缓存起来。
3. SourceFunction将当前Binlog Position写入状态后端：比如RocksDB或文件系统。
4. Checkpoint完成：SourceFunction恢复发射数据。

如果任务失败，Flink会从最近一次成功的Checkpoint恢复。SourceFunction会从保存的Binlog Position重新开始读取。这就保证了“不丢”。

那“不重”呢？这需要下游Sink的支持。比如写入Kafka时，可以开启幂等性生产者；写入HBase时，可以利用行键的唯一性做去重。Flink CDC本身只保证“至少一次”（At-Least-Once）的读取语义，结合下游的幂等写入，才能实现端到端的Exactly-Once。