变更数据捕获从数据库提交日志派生可消费的数据变化

变更数据捕获（CDC）把数据库中已经提交的插入、更新和删除转换为下游可消费的变化记录。它常用于搜索索引、缓存、分析仓库和跨系统同步。CDC 关注的是数据库事实如何传播，不等同于业务领域主动发布的事件；一行字段变化可能没有完整业务意图。

从提交日志读取变化

关系数据库通常先把事务变化写入预写日志，再更新数据页。基于日志的 CDC 从日志中解码逻辑变化，避免周期性扫描整表，也通常能保持事务内顺序。PostgreSQL 逻辑解码从 WAL 提取持久化变化，由输出插件转成特定格式，并通过复制槽跟踪消费者尚未确认的位置。

复制槽可以防止所需 WAL 被过早回收，但消费者长期停滞会导致日志持续保留并占满磁盘。槽本身因此是需要监控和回收策略的持久资源。删除消费者之前必须确认槽是否仍被使用，不能只停应用而留下无限增长的保留点。

逻辑变化只有在事务提交后才对外成立。跨多行事务如果被逐条消费，下游可能短暂看到不完整状态。事件格式应保留事务标识、提交位置和顺序，消费者根据用途选择逐条应用或按事务原子处理。大型事务还会增加延迟和内存压力。

新消费者通常既需要历史全量数据，也需要后续增量。先查全表再启动日志消费会在两者之间留下缺口；先启动消费再查全表又可能产生重复。可靠流程要获取一致快照及其日志位置，再从该位置继续消费，并为重复记录设计幂等处理。

快照期间源表仍可能变化。数据库隔离级别、快照时点和 WAL 保留必须配合。大表快照会消耗 I/O、延长事务并增加日志保留，不能在生产高峰无预算执行。分表或分区快照虽然降低单次压力，却需要额外边界来确认每部分与增量的衔接。

恢复时也要知道消费者最后持久化的位置。只把偏移保存在内存中，进程崩溃后无法判断哪些变化已经作用于下游。偏移提交与下游写入若不在同一事务边界，就要接受至少一次处理并用业务键、版本号或去重表处理重复。

数据库列的新增、删除、类型变更和默认值会改变 CDC 记录。生产者数据库可以完成兼容迁移，但下游反序列化仍可能失败。变化格式应携带模式版本，并在删除或改变含义之前确认全部消费者已经迁移。

更新记录可能只包含变化列，也可能包含完整新行。删除记录若缺少稳定主键，下游很难定位对象。主键变化还可能表现为删除加新增。为不同表设计统一包络时，应保留操作类型、源表、键、提交时间、日志位置和模式版本，同时避免暴露不应离开源库的敏感列。

CDC 记录不自动等于领域事件。status 从一个字符串变成另一个字符串，只描述存储差异，不说明谁批准了操作、业务原因或规则版本。需要业务语义时，应由应用显式产生事件，或通过事务性发件箱把业务事件与状态更新一起提交。

单个数据库日志有明确位置，但进入消息系统后可能按表、键或分区并行。全局顺序成本高且通常没有必要；更实际的是定义每个实体或聚合需要保持的局部顺序。分区键选择错误会让同一对象的更新进入不同分区。

网络重试、故障转移和偏移恢复会产生重复。消费者不应假设“恰好一次”来自某个中间组件就覆盖了全部链路。下游写入、外部调用和偏移提交之间仍可能失败。按源位置或实体版本去重，并让重复应用产生相同结果，更容易验证。

乱序不能只靠时间戳判断。不同主机时钟有偏差，业务时间也可能早于写入时间。应优先使用日志位置、事务序号和实体版本；允许并行的不同实体之间则无需强行排序。

关键指标包括源端 WAL 增长、复制槽滞后、捕获延迟、消息积压、消费者应用延迟、解析失败、重复数和死信。延迟应分解为提交到捕获、捕获到发布、发布到应用，才能定位瓶颈。

权限应遵循最小化原则。CDC 账号可能读取整表历史和删除前值，风险往往高于普通查询账号。字段过滤、传输加密、消息保留期限和下游访问控制需要统一设计。源数据删除后，已传播副本如何删除也必须进入生命周期规则。

演练应覆盖消费者停机、槽滞后、模式不兼容、源库故障转移、消息重复和下游重建。恢复标准不只是进程重新连接，还包括位置连续、数据对账和旧槽清理。CDC 是一条持续运行的数据链路，而不是打开数据库开关后即可忽略的功能。

CDC 链路稳定运行仍可能存在历史缺口、过滤错误或消费者逻辑缺陷。应定期按主键范围、时间窗口或分区比较源端与下游的行数、校验摘要和关键聚合，并能从差异追到日志位置。对账发现问题后，要有不覆盖新数据的局部重放或重新快照流程，而不是依赖人工修改下游记录。