变更数据捕获

观察提交日志

应用层双写很脆弱：数据库提交成功，事件发布却可能失败。CDC 在提交后读取数据库日志并发出变更。事实来源仍是数据库，事件流由它派生。连接器记录日志位置，重启后从该位置继续。

{
  "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
  "database.hostname": "db",
  "database.dbname": "app",
  "table.include.list": "public.orders",
  "plugin.name": "pgoutput",
  "slot.name": "orders_cdc"
}

示例是 Debezium 连接器配置。细节随平台而异；不变的是持久日志位置和一致的起始快照。

快照加流式读取

新的消费者需要现有行以及快照之后的每一次变更。连接器执行一致性快照，记录对应的日志位置，然后从该位置流式读取。只从最新偏移开始而不做快照，会让下游存储缺少全部历史数据；快照与位置不匹配则可能重复或跳过变更。

投递与模式

CDC 流通常是至少一次投递，消费者必须按主键或事件 id 幂等。行变更描述的是数据库，而不一定是业务事件；如果消费者需要“订单已发货”的语义，应读取 outbox 或领域事件，而不是从列更新推断意图。模式变更需要兼容演进策略：宽容地增加列、给事件信封加版本，并在破坏性变更时暂停管道。

何时使用

当其他系统需要响应已提交的数据库变更，而应用无法可靠地自行发布事件时，使用 CDC。优点是不用双写也能解耦；缺点是运维复杂：复制槽、连接器存活、模式演进和快照大小。与 outbox 相比，CDC 侵入性更小，但暴露存储层细节并依赖数据库特定工具。