电商订单超时未支付的异步处理采用rabbitmq死信队列+消息级ttl实现精准延迟触发，消息仅含orderno、expireat等轻量字段，消费者幂等校验状态后执行关单；失败消息进入递增ttl重试队列，最终转入人工干预队列；并发场景下通过select for update与条件update保证互斥。
电商订单超时未支付的异步处理，核心是用 RabbitMQ 延迟消息触发状态检查，避免轮询或定时任务带来的资源浪费和精度问题。关键不在于“发消息”，而在于“精准、可靠、可重试地触发超时逻辑”。
用死信队列 + TTL 实现延迟消息
RabbitMQ 本身不支持原生延迟队列，但可通过 TTL（Time-To-Live）+ 死信交换机（DLX）组合模拟。订单创建时，把订单 ID 和必要信息（如订单号、创建时间）发到一个带 TTL 的队列（例如设为 15 分钟），该队列配置死信交换机，消息过期后自动路由到监听队列，由消费者执行超时校验逻辑。
- 声明一个普通队列时，设置 x-message-ttl（单位毫秒）和 x-dead-letter-exchange（指向业务交换机）
- 死信交换机绑定一个真正的消费队列（如 order.timeout.check），消费者监听该队列做后续处理
- 注意：TTL 设置在队列级别是整队统一过期，推荐设置在消息级别（发送时指定 expiration 字段），更灵活且避免前序消息阻塞后续消息过期
消息体设计要轻量且可幂等
发往延迟队列的消息，只传最小必要字段：订单号、商户 ID、预期超时时间戳（非当前时间）。不传订单详情或用户信息，避免消息过大、序列化开销高，也防止下游服务因消息内容变更导致兼容问题。
- 用 JSON 或标准序列化（如 Jackson）封装，字段名保持简洁明确（如 orderNo, expireAt）
- 消费者收到消息后，先根据 orderNo 查询数据库最新订单状态；若状态仍是“待支付”，再执行关单、库存回滚、通知等操作
- 必须做幂等控制——比如用 Redis 记录已处理的 orderNo + 时间戳，或数据库唯一索引约束补偿操作
异常与重试要闭环，不能丢消息
超时检查失败（如 DB 连接超时、库存服务不可用）不能直接丢弃消息。需设计重试机制，并区分临时失败与永久失败。
- 消费失败时，将消息重新投递到一个带递增 TTL 的重试队列（如第 1 次 30s 后重试，第 2 次 2min 后，最多 3 次）
- 最终仍失败的消息，转入死信队列人工干预，或写入告警表 + 发送企业微信/钉钉通知
- 禁止用 throw new RuntimeException() 粗暴让消息重回队列——可能造成无限循环，应显式调用 channel.basicNack() 并指定 requeue=false
上线前必须验证时序边界和并发安全
真实场景中，用户可能在超时前最后一秒完成支付，而延迟消息恰好到达。此时必须保证“支付成功”和“超时关单”两个操作互斥。
- 在关单逻辑里加数据库行锁：SELECT ... FOR UPDATE WHERE order_no = ? AND status = 'WAIT_PAY'
- 更新状态时用条件更新：UPDATE order SET status = 'CLOSED', close_time = NOW() WHERE order_no = ? AND status = 'WAIT_PAY'，检查影响行数是否为 1
- 压测时重点模拟高并发下单 + 紧邻超时点支付，验证不会出现“已支付又被关单”或“漏关单”
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
