- 业务双写：订单更新时顺便同步到数仓 → 问题是强耦合，以后可能变成三写、四写，而且任一边失败都难处理一致性
- 定时扫表：周期性扫描订单表找增量 → 实现简单，但实时性差，而且大表扫描会给主库带来压力
- CDC：既想实时，又不想侵入业务、反复扫表 → 监听 Binlog 捕获数据变更，因此更适合作为主方案
- Kafka 缓冲：CDC 和数仓处理速度可能不一致 → 中间加 Kafka 解耦并承接峰值
- 位点：同步可能中断 → 记录 Binlog Position / GTID / Offset，支持断点续传
- 失败重试：下游写入可能失败 → 失败后重新处理，避免数据丢失
- 幂等：重试可能产生重复数据 → 按订单 ID、版本等保证重复写不会写错
- 对账：链路再可靠也可能有极端漏数、错数 → 定期分批做聚合校验，异常范围再下钻明细
- 补偿 / 重建：发现历史数据不一致 → 局部补数据，严重时全量重建
- 批量写入：逐条写数仓开销太大 → 批量提交，提高吞吐
- 并行消费：单消费者吞吐有限 → Partition / 多消费者并行处理
- 小批次 / 短等待：批次太大会增加同步延迟 → 控制批次大小和等待时间，平衡吞吐与实时性
最后主线就是：
双写太耦合 → 扫表太慢且有压力 → 选 CDC → Kafka 缓冲 → 位点/重试/幂等保准确 → 对账重建兜底 → 批量并行提吞吐 → 控制批次保低延迟。