告别 Kafka！DataMover 如何基于 Debezium Embedded 实现轻量级实时同步？告别 Kafka

在数据驱动的时代，CDC（Change Data Capture）技术是连接业务数据库与数仓/数据湖的血管。市面上主流的 CDC 方案如 Flink CDC 依赖庞大的计算集群，而云厂商的 DTS 又无法私有化。

DataMover 作为一个企业级一站式数据迁移平台，选择了一条独特的路径：基于 Debezium 1.9.8 实现 Embedded (嵌入式) 架构。本文将深入其源码与设计层面，解析它是如何在不依赖 Kafka 的情况下，实现秒级延迟、断点续传和高可用的。

在集成 Debezium 时，通常有两种选择：Server 模式（独立进程 + Kafka）和 Embedded 模式（嵌入库）。

DataMover 选择了 Embedded 模式，这一决策背后是对“轻量化”和“部署成本”的极致追求。

表格

架构图示：

DataMover 的 CDC 模块并非简单的 Debezium 封装，而是进行了深度的工程化改造，主要体现在以下三点：

1. 插件化与责任链模式

插件化：利用 Java SPI 机制，将 MySQL、Oracle、PostgreSQL 等 40+ 数据源解耦。新增数据源只需实现接口，无需改动核心代码。
责任链：数据流经 解析 -> 转换 -> 路由 -> 写入 四个阶段。这种设计使得每个环节职责单一，便于扩展（例如在转换层加入数据脱敏逻辑）。

2. 基于 MySQL 的位点持久化 (Offset Storage)
这是与官方 Debezium 最大的不同点。官方通常推荐使用 Kafka 来存储 Offset，但 DataMover 将 Offset 存储在了 MySQL 元数据库 中。

设计考量：去除了对 Kafka 的强依赖，降低了运维复杂度。
实现细节：Worker 每 6 秒将当前消费的 Binlog 位点（File Number + Position）刷写到 MySQL。任务重启时，优先从 DB 读取位点，实现了真正的断点续传。

3. 智能的异常降级机制 (Fallback Strategy)
在生产环境中，数据往往是脏的。DataMover Writer 设计了一套优雅的三级降级链路，保证任务不挂：

1. UPDATE 语义的精确处理
在 Debezium 的事件结构中，UPDATE 事件包含 before 和 after。

坑点：如果目标库主键发生变化，或者目标库有非空约束，直接使用 after 可能导致定位失败。
DataMover 的解法：在生成 UPDATE SQL 时，WHERE 条件严格使用 before 中的主键/唯一键。这保证了即使业务逻辑修改了主键字段，也能精准定位到旧记录。

2. 快照 (Snapshot) 与流式 (Streaming) 的无缝衔接
首次启动任务时，Debezium 会先执行 Snapshot（全量读取）。

挑战：如何在全量读取的同时，不丢失增量数据？
原理：
1. 获取当前 Binlog 位点 �1P1 。
2. 加锁（可配置无锁）读取全表数据。
3. 读取完成后，移动到位点 �2P2 ，开始消费 �1P1 到 �2P2 之间的增量日志。
  DataMover 默认关闭了锁表，通过 RR 隔离级别或无锁快照技术保证一致性。

在落地过程中，我们遇到了几个典型的“坑”，希望能给大家带来启发：

DDL 变更的治理：
Debezium 本质上是解析日志，它并不直接执行 DDL。如果源库新增字段，Debezium 会报错 Schema 不匹配。
- 最佳实践：Schema 变更需人工介入。先在目标库 ALTER TABLE，再刷新 DataMover 的元数据。这是为了防止自动化工具误删生产库字段。
时间类型的精度陷阱：
MySQL 的 DATETIME(6) 在 Java 中是纳秒级 Long。如果直接写入 ClickHouse 或 Doris，可能会截断精度。
- 解决方案：DataMover 在转换层增加了纳秒处理器，自动将 Long 转换为 yyyy-MM-dd HH:mm:ss.SSSSSS 格式。

DataMover 的 CDC 方案，本质上是在功能完备性与部署简易性之间找到了一个平衡点。

通过 Debezium Embedded 模式，DataMover 证明了：在不需要复杂 Flink 作业的情况下，我们依然可以构建出高可靠、低延迟的企业级数据同步平台。

告别 Kafka！DataMover 如何基于 Debezium Embedded 实现轻量级实时同步？