如何保障两个微服务（M1与M2）间的数据一致性？

本质是消息传递的可靠性缺失——M1发送消息后未确认M2的处理结果，导致M2处理失败时数据直接丢失，无法补全报表。

一、强化消息总线的可靠性 #

• 启用手动ACK机制：给消息总线（比如RabbitMQ、Kafka）配置手动确认模式。M2成功处理完消息后，主动向消息总线发送ACK；如果处理超时或抛出异常，消息总线自动重投该消息（可设置重试次数），直到M2确认或触发死信队列。
• 死信队列兜底：把多次重试仍失败的消息放到死信队列，后续通过定时任务人工排查原因，修复后重新投递，避免数据永久丢失。
• 开启消息持久化：确保消息在发送前就持久化到磁盘，就算消息总线重启，未处理的消息也不会丢失。

二、事件溯源+定时对账 #

• 双端记录事件日志：M1在订单完成后，存一份订单完成日志（含参考号、时间戳、事件类型）；M2成功生成报表后，存一份报表生成日志（关联对应订单参考号）。
• 定时比对补全：用独立的对账服务（或内嵌定时任务），定期拉取双方的日志，通过参考号匹配。找出M1有记录但M2没有的订单，直接触发M2补生成报表。
• 时间戳分段校验：比对时按时间戳分片（比如每2小时处理一次），不用纠结“最后一个参考号是否最新”，每次只处理固定时间窗口内的数据，确保新增订单不会被遗漏。

三、主动补偿+幂等保护 #

• M1新增消息状态追踪：M1发消息后，记录消息状态（待处理、已成功、失败），并设超时时间。如果超时没收到M2的确认，自动重发消息。
• M2接口做幂等：因为可能重复投递，M2要通过订单参考号判断是否已生成过报表，避免重复生成或数据冲突。

四、原拉取方案的优化 #

如果不想改推送模式，可优化原拉取逻辑：

• 按时间分片拉取：不再依赖“最后一个参考号”，改成按时间段拉取订单（比如每小时拉一次），拉取后和M2的报表数据比对，缺失的立即补全。
• 新增同步标记：M1给每个订单加“已同步”标记，M2只拉取未同步的订单，拉取成功后M1更新标记；拉取失败的话，标记保持未同步，下次继续拉。

内容的提问来源于stack exchange，提问作者Siraj ur Rahman