如何在异步（事件驱动）系统中检查数据完整性与一致性？

核心校验目标拆解 #

你关注的三个核心问题，对应着不同的校验方向：

• 事件生成代码正确性：验证服务A生成的事件是否与源数据变更完全匹配
• 传输过程消息丢失：确认事件从A发出后，中间件是否完整投递到B
• 消费端代码正确性：验证B消费事件后写入的数据是否与事件内容一致

对你们提出思路的评估 #

• 思路1：以事件流为可信源，校验源数据库与事件流同步
  这个方案完全可行，是增量校验的核心思路，落地可以这么做：

  • 给服务A的源数据变更加上全局递增的版本号/操作ID，同时事件中携带这个标识
  • 定期（或触发式）对比源数据库的最新版本号和事件流中最新的版本号，若存在缺口则说明有事件漏发
  • 针对单个数据条目，通过版本号回溯事件流，验证每一次变更事件是否与源数据的历史变更匹配
  • 优势：无需侵入服务A的核心业务逻辑，仅需在数据变更时追加版本标识

• 思路2：切换至事件溯源模式，但不想重写服务A
  可以采用混合模式规避大规模重写：

  • 给服务A的数据库变更加上触发器，捕获所有数据变更操作，自动生成事件写入事件流（把事件生成从业务代码剥离到数据库层）
  • 保留原业务代码的同时，用触发器生成的事件作为可信源，和原业务代码生成的事件做对比，校验业务代码的事件生成逻辑是否正确

• 思路3：在服务A暴露同步端点用于校验和修复
  这是全量校验的常用兜底手段：

  • 端点支持按数据范围（时间区间、ID范围等）返回服务A的源数据快照
  • 服务B定期拉取快照，和本地数据做全量对比，定位不一致条目
  • 针对不一致条目，可通过端点获取完整变更历史，反向修复B的数据或触发事件重放
  • 注意：控制拉取粒度，避免单次拉取数据量过大影响服务A性能

• 思路4：忽略问题寄希望于一致
  除非系统对一致性要求极低，否则不建议采用。一旦出现数据不一致，排查成本极高，甚至可能引发业务故障

补充实用校验手段 #

除了你们提出的思路，还有一些落地性强的方法：

• 事件幂等校验：服务B消费事件时记录已处理的事件ID，定期比对事件流中的所有事件ID和B的处理记录，找出未处理的事件（排查传输丢失或消费漏处理）
• 采样实时校验：对关键数据，在服务A发布事件后立即调用服务B的查询接口，对比数据是否一致（实时验证事件生成、传输、消费全链路）
• 死信队列监控：监控死信队列的事件增长，分析消费失败原因（比如消费代码bug、事件格式错误）

内容的提问来源于stack exchange，提问作者Lukáš Křečan