CodeWalk

Debezium CDC实现与容错机制

作者：专业代码师 · 2026-05-30 12:55

Debezium作为分布式CDC平台，如何实现MySQL/PostgreSQL/MongoDB的实时变更捕获？请说明Debezium的Kafka Connect架构、Snapshot与增量模式、Schema变更处理、以及容错和Exactly-Once保障机制。与Canal相比有何优劣势？

回答

专业代码师

1. Debezium架构

MySQL → Debezium MySQL Connector (Kafka Connect) → Kafka
                                  ↓
                          Kafka Connect Worker集群

核心组件：

  • Source Connector：连接数据库，读取变更日志
  • Offset Storage：记录消费进度到Kafka Topic或DB
  • Schema Registry（可选）：管理Schema演进

2. Snapshot与增量模式

Snapshot阶段（首次启动）：

{
  "snapshot.mode": "initial",  // 先快照后增量
  // 读取全表数据为INSERT事件
  // 记录Binlog位置
  // 切换到增量模式
}

增量模式：

持续监听变更日志
每条变更生成Kafka消息
消息包含：before/after/source元数据

3. Schema变更处理

// DDL变更事件
{
  "schema": { ... },
  "payload": {
    "source": {"db": "shop", "table": "orders"},
    "op": "c",  // create
    "ddl": "ALTER TABLE orders ADD COLUMN new_col INT"
  }
}

演进策略：

  • 默认兼容模式（保持向后兼容）
  • Schema Registry统一管理

4. 容错与Exactly-Once

# 容错机制
offset.storage.topic = connect-offsets
# 利用Kafka事务实现Exactly-Once

# 重启恢复流程：
1. 从Offset Topic读取最后提交偏移量
2. 重新连接数据库
3. 从断点继续消费Binlog

5. Canal vs Debezium对比

维度CanalDebezium
架构自研ServerKafka Connect
支持的DBMySQL为主MySQL/PG/MongoDB/SQL Server
部署复杂度低中（依赖Kafka Connect）
Schema演进一般强（Schema Registry）
Exactly-Once至少一次支持（Kafka事务）
社区生态国内为主国际社区活跃

6. 最佳实践

  • 使用Kafka Connect分布式模式
  • 设置 tombstones.on.delete=false
  • 监控 source.ts_ms 和 ts_ms 差异
  • 为每个表分配独立Topic（topic.routing）