CDC 如何在多个系统之间同步数据？

Question

CDC 如何在多个系统之间同步数据？

IT Interview Practice · Accepted Answer

**变更数据捕获（Change Data Capture, CDC）**把源数据库中的每一次 insert/update/delete 流式导出——通常通过**读取其事务日志（transaction log）**——并把它们作为事件发布，供其他系统消费，因此下游存储无需双写或轮询即可保持同步。

```text
  Postgres/MySQL          Debezium            Kafka topic          sinks
 ┌────────────┐  reads   ┌─────────┐  emit   ┌──────────┐  consume ┌───────────┐
 │ WAL/binlog │ ───────▶ │ connector│ ──────▶ │ per-table│ ───────▶ │ search    │
 │ (tx log)   │          │          │  events │  ordered │          │ warehouse │
 └────────────┘          └─────────┘          └──────────┘          │ cache     │
                                                                     └───────────┘
```

## 为何采用基于日志的 CDC

你可以通过轮询（"自 T 以来变更的行"）或同时写入两个系统（**双写**）来同步，但轮询会漏掉快速更新，而双写在原子性上会失效——如果第二次写入失败，你就会得到分叉。**基于日志的 CDC** 则跟踪数据库自身的 write-ahead log（Postgres 的 **WAL**、MySQL 的 **binlog**），即 DB 用于崩溃恢复的持久记录。**Debezium** 是标准的连接器（connector）：它读取日志并把每个变更发布到 **Kafka**，每张表一个 topic——捕获*每一个*变更，对查询没有负载，也不漏行。

## 顺序与幂等性

- **顺序：**对同一行的变更必须按顺序到达，否则你会把一个旧值最后应用。Kafka 保证 **partition 内**的顺序，因此按主键 partition——一行的所有变更都落在一个 partition 上，按提交顺序排列。
- **投递是 at-least-once 的：**在重试或连接器重启时，同一个事件可能被投递两次。因此 **sink 必须是幂等的**——用主键 + 日志偏移（LSN）作为写入的键，使重新应用一个事件成为无操作（no-op）。绝不要假设 exactly-once。

## 面试视角

面试官检查你是否知道 CDC 胜过双写以及*为什么*（原子性、不漏变更），以及你是否掌握 **at-least-once + 幂等 sink**。好："Debezium 把 WAL 读入 Kafka。"出色：你为顺序加上按键 partition，为重复加上幂等 sink。陷阱：假设 exactly-once 投递，或忽视源上的一次 DDL 变更可能破坏消费者。

## 权衡与故障模式

- **Schema 演进：**上游增删一列会改变事件的形状——使用 **schema registry** 和兼容性变更，使消费者不会崩溃。
- **初始快照：**CDC 只看到*从现在起*的变更；你需要对现有行做一次性快照，然后切换到流式。
- **日志保留：**如果源在连接器读取之前清除了日志，你会丢失变更——监控连接器 lag。
- **反压：**一个慢的 sink 会让 Kafka lag 增长；按峰值变更量来设置保留和消费者规模。

为何采用基于日志的 CDC

顺序与幂等性

面试视角

权衡与故障模式

相关问题