盘点数据重复消费故障复盘与修复方案评审

会议时间：2026-05-27

发言人：梁健、王建朝、贾继伟、孙传熙、吕杰等7人

会议摘要：会议复盘了因RPC报错导致盘点数据重复消费的故障，制定了双重去重拦截的技术修复方案，并对历史脏数据的清洗策略及业务管家下线影响进行了评估。

一、故障根因与修复方案

针对客户反馈的"同一码在同一天出现多次盘点记录"问题，团队进行了根因分析并制定了技术修复方案：

1. 故障根因定位

RPC报错引发重试逻辑缺陷：原有代码在处理盘点数据时，遇到RPC报错后会跳转到重试方法，导致已处理成功的码被重复消费，从而产生大量重复数据。
事务缺失与数据一致性风险：由于盘点组装数据过程缺乏事务控制，且RPC报错导致消息重复消费，造成数据库中存在大量重复记录。

2. 双重去重拦截机制

消费端去重拦截：在消息消费前，根据"订单+码"组合查询数据库，若已存在记录则移除该码，仅处理未落库的数据，确保即使报错也不会重复处理已成功的数据。
落库端Upsert操作：在RocketMQ消费逻辑中增加拦截，根据Check ID和码进行过滤，若已存在则执行更新操作，不存在才执行插入操作，实现幂等性。

二、历史数据清洗策略

针对已产生的脏数据，团队讨论了清洗方案及业务规则约束：

1. 清洗逻辑与约束

保留单日首条记录：若需清洗数据，计划按天分组并保留创建时间最早的一条记录，删除其余重复数据。
盘点次数不可修复：由于盘点次数存储在MongoDB中且已累加，无法通过清洗数据库记录来修正，若删除中间记录会导致后续盘点次数不连续。

2. 特殊业务场景排除

业务管家下线确认：经确认，允许一天多次盘点的"业务管家"功能已于今年下线，目前无相关数据产生，因此历史数据清洗不受该特殊规则影响。

三、技术方案风险评估

1. 数据一致性保障

消息重试机制验证：确认RocketMQ在服务宕机或未ACK的情况下会重新投递消息，不会导致数据丢失，仅可能因重复消费导致数据冗余。
Stream Load延迟风险：针对Stream Load写入延迟可能导致去重失效的担忧，团队确认在"一天一盘"的业务校验下，该极端情况不会发生。

2. 业务逻辑修正

盘点次数累加逻辑调整：纠正了原有在报表中累加次数的错误逻辑，改为在同步接口中直接累加，确保数据来源的准确性。

四、待办事项

确认是否需要对历史脏数据进行清洗，并明确清洗的具体需求。@梁健 @罗宾
编写并发送本次修复方案的测试报告。@马奇