在中能元器件交易与技术交流平台的开发中，我接触较多的是“消息最终会来，但不一定只来一次，也不一定按预期顺序来”的问题。

回调先快速确认

微信回调需要尽快返回 ACK。耗时的 AI 回复不应阻塞回调线程，因此处理链路拆为：

  1. 校验并记录消息；
  2. 使用 Redis 完成重复消息过滤；
  3. 快速返回 ACK；
  4. 异步执行 AI 回复；
  5. 必要时通过客服消息接口补发结果。

使用监听模型管理 RabbitMQ

原有手写连接池和轮询消费被替换为 Spring AMQP 监听模型。ACK/NACK 决定消息去向，死信队列隔离持续失败的任务，Redis TTL 锁则用于减少短时间内的重复互动通知。

支付回调的幂等

微信和支付宝支付回调都可能重复到达。订单处理需要把“收到通知”和“状态实际发生变化”分开：通过分布式锁、业务幂等键和状态机校验保证同一个订单不会被重复结算，再通过异步消息推进后续业务。

这些机制并不只服务于支付。凡是跨网络、跨进程的消息链路，都应默认面对超时、重试、重复与乱序。