直接回答：CDC 是把数据库的增删改变更实时捕获并分发的技术。实现方式：查询轮询（WHERE updated_at > ?，丢删除、有时钟偏差问题）；触发器（侵入业务库、性能开销）；日志解析（解析 MySQL binlog/PG WAL，零侵入、含删除、顺序可靠，Debezium/Canal 走这条路）。相比应用双写（代码里同时写 DB 和 MQ/ES），日志 CDC 的优势是根本性的：双写在两个系统间没有事务，任何一次部分失败就数据不一致，且绕开应用的变更（DBA 直接改库）完全丢失。

展开解析：架构形态：CDC 工具读日志把变更转成事件发 Kafka，下游消费者各取所需——同步搜索引擎、失效缓存、灌数仓、审计。关键工程点：顺序保证按主键分区，同一行的变更顺序消费；schema 演进要靠 Schema Registry 约束；快照加增量的衔接（先全量 snapshot 再无缝切增量，Debezium 已处理）；至少一次语义要求消费者幂等（按主键 upsert 天然幂等）。边界要清楚：CDC 是最终一致（毫秒到秒级延迟），不能用于要求强一致读的场景；大事务会产生延迟尖刺；DDL 变更需要发布流程配合。它也催生了 outbox 模式：业务表加 outbox 表同事务写入，CDC 发 outbox——这是微服务可靠事件发布的标准解法。

追问方向：outbox 模式解决什么原子性问题？CDC 事件的 exactly-once 为什么通常不在管道层做？binlog 的 row 格式为何是前提？

（约 460 字）