如何保证并发和分布式消息消费的业务幂等？

核心回答

消息消费的业务幂等，是让同一业务动作被重复或并发触发时，不产生额外的业务副作用。重点是业务状态的约束和失败恢复，不能只靠消费者“先查一下是否处理过”。

通常按以下流程设计：

1. 定义稳定的业务幂等键：例如订单创建请求号、支付流水号、短信任务号，并区分动作类型和消费方。重试同一动作复用同一个键，不能每次都生成新号。
2. 原子判断并执行：通过数据库唯一约束、条件更新或状态机决定谁能处理，避免两个消费者都查到“未处理”后一起执行。
3. 本地事务一起提交：去重记录、相关业务修改和本步成功结果放在同一个数据库事务中，避免只写了“已处理”却没完成业务，或业务完成却没有记录。
4. 提交后再确认消费：成功提交后才 ACK 或提交消费进度；若提交后确认前宕机，重投时读取已提交结果，不再重复产生业务效果。
5. 外部副作用单独处理：短信、支付等远程调用不能直接和本地数据库事务原子提交，需要下游幂等请求号、结果查询和持久任务恢复等能力配合。

进程内锁只协调本实例，Redis 锁可以减少多实例竞争，但都不能替代持久业务约束；消息系统的投递保证也不能直接延伸成“外部业务永远只执行一次”。

为什么先查询、再处理不够？

假设两个消费者同时收到同一个下单事件，都查到没有创建订单，然后各自插入，普通查询本身没有排他性。

可以给订单创建请求号加唯一约束：同一请求并发插入时，由数据库决定谁成功。也可以让任务状态通过条件更新，从“待处理”转成“处理中”，只有成功完成状态转换的执行者继续。重点是把检查与占有执行资格合成一个原子动作，而不是把两条普通操作写在相邻位置。

幂等键要表示业务意图。例如一次订单创建与一次短信发送是两个动作，不应只用同一个订单号把它们互相去重；用户确实再次下单，也应有新的请求号。相同幂等键却带了不同金额、收件人等关键参数时，应识别冲突，不能静默当作同一次操作。

本地事务和消费确认怎样衔接？

以同库订单修改为例，可以在一个事务中插入带唯一约束的消费记录、修改订单并记录成功结果。并发重复请求发生唯一键冲突时，要确认已有的成功结果，再按重复完成处理；普通数据库异常不能一律当成重复消息吞掉。

三个失败位置需要分清：

• 本地事务提交前失败：业务和去重记录一起回滚，消息重投后可以重新执行。
• 事务已提交，ACK 前失败：业务已完成，重投会命中持久记录，跳过副作用后重新确认。
• 先 ACK，再执行业务时失败：消息系统可能已经不再投递，本次业务就可能丢失，因此不能把确认放在可靠处理之前。

若将“处理中”状态单独提交来认领长任务，还需要记录执行归属、尝试次数或版本，并设计超时恢复。看到“处理中”只能说明曾被接管，不能证明业务成功；重新认领时也要防止旧执行者恢复后继续提交结果。

下单后发短信，怎样避免重复发送？

可以先在订单事务中创建具有唯一任务号的持久短信任务，把“订单成功”和“需要发送短信”一起记录下来。若 MQ 消费职责是可靠登记这个任务，登记事务提交后即可确认消费；独立发送器再认领任务、调用短信平台并记录结果。

不过，这只能可靠保存发送意图，不能消除远程调用的不确定性：短信平台可能已接受发送，但成功响应丢失；发送器重启后只看到本地还没标成功，直接重发就可能重复。

如果平台支持幂等请求号，应让同一短信任务的重试复用该号，并确认它的去重范围与保留期限；支持可靠结果查询时，可先查询并恢复本地状态。若平台既不能去重、也无法查清结果，仅靠本地锁和状态表，就无法同时保证绝不重复、绝不漏发，需要将不确定任务纳入对账和明确的重试策略。

常见追问

Redis SET NX 去重可以吗？ 可以作为短期拦截，但它与数据库修改分属不同系统。先写去重键后业务失败，可能错误拦住后续重试；业务成功后还没写去重键就宕机，又可能重复处理。TTL 到期、故障切换或缓存丢失也会让历史去重信息消失，重要业务仍应有持久约束。

去重记录保存多久？ 至少覆盖可能的延迟投递、重试、死信重放和业务补发范围。没有通用 TTL；超过窗口的历史重放，应仍能被业务唯一约束、版本或状态机识别，不能删完记录就默认安全。

幂等也能解决乱序吗？ 不能直接解决。两条不同的事件都可能只执行一次，却按错误顺序把新状态覆盖成旧状态；还需要按业务版本、允许的状态转换或顺序处理规则约束。

参考资料