2、CDC架构基础：核心组件与数据流转
聊CDC延迟，得先搞清楚数据到底是怎么从源头跑到消费端的。我见过不少团队，一上来就追着问“为什么延迟高”，结果连Source Connector和Sink Connector的区别都没理清。说白了，延迟的根因往往就藏在这些组件的协作细节里。
这一节，我们先把CDC的骨架搭起来。你理解了核心组件和数据流转路径，后面排查延迟时才能精准定位——到底是源头卡住了，还是中间传输堵了，或者是消费端写不进去。
2.1 CDC三大核心组件
一个标准的CDC管道，通常由三个角色组成。嗯，这里我用Debezium + Kafka的架构来举例，因为这是目前最主流的组合。其他工具（比如Canal、Maxwell）虽然实现细节不同，但逻辑分层是类似的。
核心结论：Source Connector负责“读”，Connect Runtime负责“传”，Sink Connector负责“写”。延迟可能出现在任何一个环节。
2.1.1 Source Connector（源端连接器）
Source Connector的任务，就是从源数据库里抓取变更数据。它怎么抓？主要有两种方式：
- 基于日志解析（Log-Based）： 比如Debezium读取MySQL的binlog、PostgreSQL的WAL。这是主流方式，对业务库侵入最小。
- 基于轮询（Polling-Based）： 比如Canal早期版本或一些自研工具，通过SELECT查询来捕获变更。这种方式延迟高，且容易给源库造成压力。
我个人习惯把Source Connector比作“哨兵”。它蹲在数据库旁边，一旦发现有数据变化（INSERT、UPDATE、DELETE），就立刻把变化记录抓出来，转成统一格式（比如Debezium的Change Event）。
避坑指南：我曾经遇到过一个案例，Source Connector配置的binlog读取位置不对，导致它一直在重复读取旧数据，新数据的变更根本进不来。排查了半天，最后发现是offset提交策略的问题。所以，Source Connector的offset管理是延迟排查的第一个检查点。
2.1.2 Connect Runtime（运行时引擎）
Connect Runtime是CDC管道的“心脏”。它负责管理Connector的生命周期、分配任务、处理offset提交，以及最重要的——数据缓冲和分发。
在Kafka Connect架构中，Runtime会把Source Connector产生的Change Event写入Kafka Topic，然后Sink Connector再从Topic里拉取数据。这个“写入-拉取”的过程，就是延迟最容易产生的地方。
- 缓冲机制： Runtime内部有队列，用于暂存来不及发送的数据。队列满了怎么办？要么阻塞Source Connector，要么丢弃数据——这两种情况都会导致延迟。
- 并行度： 每个Connector可以拆成多个Task。Task数量决定了数据处理的并行能力。我见过有人把Task数设为1，结果数据量一大，延迟直接飙升到分钟级。
注意：Connect Runtime的配置参数（比如offset.flush.interval.ms、task.max）对延迟有直接影响。默认配置通常只保证“能跑”，不保证“低延迟”。
2.1.3 Sink Connector（目标端连接器）
Sink Connector是管道的“终点”。它从Kafka Topic（或其他中间件）里读取Change Event，然后写入目标系统——可能是另一个数据库、数据仓库、搜索引擎，或者消息队列。
Sink Connector的延迟，往往和“写入目标系统的速度”强相关。你想想看，如果目标端是Elasticsearch，写入时要做索引、分词，速度肯定比写Kafka慢得多。
- 批量写入： Sink Connector通常会攒一批数据再写入，以提升吞吐。但批次越大，单次写入的延迟就越高。
- 幂等性： 如果Sink Connector不支持幂等写入，一旦发生重试，可能导致数据重复或顺序错乱，进而引发“假延迟”——数据其实到了，但消费端因为顺序问题一直处理不完。
2.2 数据流转路径：一条Change Event的旅程
我们来看一条数据从MySQL变更到最终写入Elasticsearch，到底经历了哪些步骤。我画了一张图，你可以对照着看。
这条路径里，每一步都可能成为延迟的瓶颈。我简单拆解一下：
- 源数据库 → Source Connector： 延迟取决于binlog的读取速度。如果数据库写入量巨大，binlog文件轮换频繁，Source Connector可能来不及消费。
- Source Connector → Connect Runtime： 这里涉及序列化和网络传输。如果Change Event体积很大（比如包含整行数据），网络带宽可能成为瓶颈。
- Connect Runtime → Kafka Topic： Kafka的写入性能是关键。分区数、副本数、acks配置都会影响这一步的延迟。
- Kafka Topic → Sink Connector： Sink Connector的拉取频率和消费能力决定这一步的快慢。如果Sink端处理不过来，Kafka里的消息会越积越多。
- Sink Connector → 目标系统： 目标系统的写入速度是最终瓶颈。比如写入HBase时，RegionServer的负载会直接影响延迟。
2.3 常见CDC工具对比
市面上主流的CDC工具有不少，但核心思路大同小异。我挑三个最常用的——Debezium、Canal、Maxwell——做个对比。你根据自己的技术栈选就行。
| 特性 | Debezium | Canal | Maxwell |
|---|---|---|---|
| 源数据库 | MySQL、PostgreSQL、MongoDB、Oracle、SQL Server等 | 仅MySQL | 仅MySQL |
| 捕获方式 | binlog / WAL 日志解析 | binlog 日志解析 | binlog 日志解析 |
| 输出格式 | Change Event（JSON / Avro） | FlatMessage / 自定义 | JSON |
| 消息中间件 | Kafka（原生集成） | Kafka / RocketMQ / 自定义 | Kafka / RabbitMQ / Kinesis |
| Schema变更 | 支持（通过Schema Registry） | 有限支持 | 有限支持 |
| 社区活跃度 | 高（Red Hat维护） | 中（阿里巴巴开源） | 低（个人项目） |
| 延迟表现 | 毫秒级（配置得当） | 毫秒级 | 秒级（受限于单线程） |
我的选择建议：如果你用的是Kafka生态，无脑选Debezium。它和Kafka Connect深度集成，配置灵活，社区也活跃。Canal适合阿里云RDS用户，或者对MySQL协议有特殊需求的场景。Maxwell嘛……我只有在做原型验证时用过，生产环境不太推荐，单线程模型在数据量大时延迟会明显偏高。
2.4 小结：理解架构，才能定位延迟
这一节我们讲了CDC的三个核心组件、数据流转路径，以及主流工具的对比。你可能会觉得这些内容偏基础，但说实话，我排查过的延迟问题里，有将近一半是因为架构理解不到位导致的。
举个例子，有人发现Sink Connector写入慢，就拼命调大Kafka的分区数。结果呢？分区数大了，Source Connector那边的写入压力反而更大了——因为每个分区都要维护一个生产者。这就是典型的“头痛医头，脚痛医脚”。