为什么需要对账系统

1. 分布式事务的最终一致性
   微服务架构中，跨服务的业务操作通常通过异步消息、补偿事务（如Saga模式）实现最终一致性。对账系统可主动发现并修复未收敛到一致状态的数据。
2. 系统复杂性导致数据不一致风险
   服务间调用链路过长、依赖外部系统（如支付网关）、网络抖动、服务故障等因素可能导致数据丢失或状态不一致（如订单已支付但库存未扣减）。
3. 外部依赖的不可控性
   与第三方系统（如银行、物流）交互时，可能出现超时、重复调用或响应丢失，导致本地状态与外部系统记录不一致。

对账系统设计策略

策略设计的重点要考虑：实时性、数据重要程度、数据量；

1. 定时离线T+1对账；
   1. 场景：数据量大、实时性要求不高的业务；可以是全量对账、增量对账（每日数据对账）
   2. 实现：定时任务扫描数据，关联本地其他数据、外部数据进行数据比对；
2. 事件驱动实时对账；
   1. 场景：实时性要求高的业务；通常是增量对账；
   2. 实现：一般是业务的终态触发一个事件（如MQ），异步关联其他数据进行比对；
   3. 举例：员工档案重构对账，支付链路完成后，执行订单、优惠券等对账；

设计要点

1. 数据的采集和标准化；
   1. 首先要明确需要核对的数据集之间的数据结构；
   2. 非结构化的日志数据、结构化的DB数据；
2. 性能；
   1. 实时对账一般要求低延时，数据的中间存储可以考虑MQ、分布式缓存；
   2. 离线数据对账通常需要对大数据集进行扫表，需要根据系统能力分批执行，防止系统过载；
3. 业务独立
   1. 对账系统通常需要较高的内存占用；
   2. 对账业务和线上业务不强相关，系统设计上比较独立；
   3. 风险隔离；
4. 扩展性；
5. 自动修复；
6. 监控告警；

对账任务是确保数据一致性、准确性和业务合规性的兜底方案；

分布式系统中一个完整的事务通常跨越多个服务、模块，对于一些较为重要的数据，可能需要设定一些对账任务，这样做的目的：

1. 在业务迭代过程中，如果出现纰漏，可以尽早发现；
2. 分布式事务难以做到完美的一致性，通过对账发现极端情况的不一致现象，尽早介入；

通常的对账系统需要关注：

1. 对账周期：
   1. 离线对账：T+1天级别对账（每日定时核对前一天的数据）、T+7周级别对账等等；通常以定时任务的方式触发。
   2. 准实时对账：在事务完成时，即刻触发对账。可以利用日志、精卫等在业务完成后，异步触发对账；（通常需要一个独立的对账服务）。数据重要程度高，时间敏感度高的业务需要，比如交易服务。
2. 增量对账和全量对账：
   1. 增量对账：新产生的事务，不会对历史数据有影响，可以按照发生时间进行增量对账，效率高；（通常用于流水数据）
   2. 全量对账：新产生的事务，对现有数据有影响，需要每次对账全量执行；（通常用于非流水数据）
3. 需要核对的数据方：
   1. 内部系统不同模块间的对账；
   2. 与外部系统对账；（与外部合作方）

对账系统：

1. 基于SQL报表的离线对账：
   1. 将各自的业务数据每日生成离线表；通过写SQL的方式，编写对账逻辑，最终生成报表，可每日订阅报表或告警，发现数据不一致现象；
   2. 与业务完全解耦，也不会占用业务资源（如机器、CPU、内存等资源）；
   3. 不同的业务各自维护对账逻辑；
   4. 缺点：需要一个完善稳定的对账平台基础设施；
2. 基于定时任务的对账：
   1. 可以业务内自行触发定时任务，也可以独立定时任务服务；
   2. 以代码的方式实现对账逻辑，更灵活；完全可以自行实现，成本低；
   3. 缺点：会占用业务资源；通常需要业务低谷执行；