对账与补偿

用途：为任何异步一致性方案补上“证据与兜底”时查阅

定义

对账是周期性比对两个或多个数据源的同一业务事实，识别差异并驱动修复的过程。补偿是对已确认差异执行的修复动作（重放事件、反向冲正、状态推进、人工处理）。

在最终一致体系里，对账不是运维附属品，而是一致性承诺的唯一可验证形式：没有对账，“最终会一致”只是信念。

对账的三个层次

层次	比什么	发现什么
笔数对账	两侧记录数量与业务键集合	丢失、重复、多出
金额/关键字段对账	逐笔比对金额、状态、时间	错值、状态漂移
明细汇总对账	按维度（日/商户/渠道）汇总核对	系统性偏差、口径不一致

先做笔数，再做字段，最后做汇总——成本递增，覆盖面也递增。

差异处理决策表

差异类型	常见原因	处理
我有他无	对方未收到/未处理	重放通知或消息
他有我无	我方丢单/落库失败	补建记录并推进状态，或反向冲正
两边状态不同	消息乱序、迟到通知	以权威源 + 版本号裁决，禁止旧数据覆盖新数据
金额不一致	计算口径、四舍五入、汇率	人工规则 + 白名单，多数不可自动修复
重复记录	幂等失效	去重并保留权威一条，审计留痕

设计要求

1. 可重入：同一批次重复执行不产生重复修复。
2. 分级：可自动修复的走任务队列；不可自动的生成工单，人工确认。
3. 留痕：每次修复记录依据、执行者与前后值，满足审计。
4. 时效：对账周期必须短于业务可容忍的不一致窗口（资金场景通常日终，重要链路小时级）。
5. 数据快照对齐：比对时点要一致，否则把正常在途误判为差异（用截止时点/水位线）。
6. 在途白名单：明确“处理中”状态不参与差异判定，避免误冲正。

实现形态

批处理任务（定时全量/增量）、流式比对（双源事件流 join 后判差异）、离线数仓比对（T+1 报表 + 差异表）。中小规模首选“增量水位 + 日终全量”的组合。

开源参考：Apache Spark / Flink（大规模比对）、DolphinScheduler / Airflow（调度）、DataX / SeaTunnel（数据抽取）。

常见误区

误区	修正
对账只出报表不驱动修复	差异必须变成可执行任务并闭环
把“处理中”当差异冲正	设立在途豁免窗口
两侧都取当前时间快照	用统一水位线，否则误报大量差异
修复动作不幂等	二次对账会把修复本身变成故障源
只做资金对账	状态类不一致（已发货未同步）同样需要核对

与其他概念的关系

• Outbox / 事务消息：投递可靠性提升后，对账负担下降但不能取消。
• Saga / TCC：补偿失败的最终兜底。
• 最大努力通知：对账是其成立的必要条件。

延伸阅读

• 支付与清算领域的对账实践（公开文档中普遍存在的“日终对账 + 差错处理”范式）
• Martin Kleppmann《数据密集型应用系统设计》第 9 章（不一致与修复）