Spring Boot 订单超时自动取消的 3 种主流实现方案

关键词：Spring Boot、订单超时、延迟任务、RabbitMQ、Redis、定时任务

在电商、外卖、票务等业务中，“下单后若 30 分钟未支付则自动取消”是一道经典需求。实现方式既要保证 实时性，又要在 高并发 下保持 低成本、高可靠。
本文基于 Spring Boot，给出 3 种生产级落地方案，并附完整代码与选型对比，方便快速决策。

---

一、需求拆解

功能点	约束
触发条件	创建时间 + 30 min 仍未支付
实时性	秒级（理想） / 分钟级（可接受）
幂等	重复取消需幂等
高并发	峰值 10 w+/日
数据一致性	不能漏单、不能错单

---

二、方案总览

方案	核心机制	实时性	额外组件	代码复杂度
① 定时任务	@Scheduled + DB 扫描	分钟级	无	★☆☆
② 延迟队列	RabbitMQ TTL + DLX	秒级	RabbitMQ	★★☆
③ Redis 过期事件	Key TTL + Keyspace Notify	秒级	Redis	★★☆

---

三、方案 1：定时任务（@Scheduled）

1. 思路

周期性扫描订单表，把“创建时间 + 30 min < 当前时间”且状态为 PENDING 的订单置为 CANCELLED。

2. 代码实现

@EnableScheduling
@Component
@RequiredArgsConstructor
public class OrderCancelSchedule {private final OrderService orderService;/** 每 30s 跑一次，可根据数据量调整 */@Scheduled(fixedDelay = 30_000)public void cancelUnpaidOrders() {LocalDateTime expirePoint = LocalDateTime.now().minusMinutes(30);List<Long> ids = orderService.findUnpaidBefore(expirePoint);if (!ids.isEmpty()) {int affected = orderService.batchCancel(ids);log.info("自动取消订单 {} 条", affected);}}
}

3. 优化技巧

• 分页 + 索引：

  CREATE INDEX idx_order_status_created ON t_order(status, created_time);
  

• 分片扫描：按 ID 或时间分片，避免大表锁。
• 单机多线程：@Async("cancelExecutor") + 线程池。

4. 优缺点

• ✅ 零依赖、实现快
• ❌ 数据量大时 DB 压力大；实时性受轮询间隔限制

5. 适用场景

日订单 < 1 w，或作为兜底方案。

---

四、方案 2：RabbitMQ 延迟队列

1. 思路

订单创建后发送一条 30 min TTL 的消息；到期自动路由到消费队列，消费者检查订单状态并取消。

2. 架构图

Producer ──> Delay Exchange (x-delayed-message) ──> 30min TTL ──> Cancel Queue ──> Consumer

3. 代码实现

3.1 声明交换机 & 队列

@Configuration
public class RabbitDelayConfig {@Beanpublic CustomExchange delayExchange() {Map<String, Object> args = Map.of("x-delayed-type", "direct");return new CustomExchange("order.delay", "x-delayed-message", true, false, args);}@Beanpublic Queue cancelQueue() {return QueueBuilder.durable("order.cancel.queue").build();}@Beanpublic Binding binding() {return BindingBuilder.bind(cancelQueue()).to(delayExchange()).with("order.cancel").noargs();}
}

3.2 发送延迟消息

@Service
@RequiredArgsConstructor
public class OrderPublisher {private final RabbitTemplate rabbitTemplate;public void createOrder(Order order) {// 1. 落库orderMapper.insert(order);// 2. 发送延迟消息rabbitTemplate.convertAndSend("order.delay","order.cancel",order.getId(),msg -> {msg.getMessageProperties().setDelay(30 * 60 * 1000); // 30 minreturn msg;});}
}

3.3 消费并取消

@Component
@RabbitListener(queues = "order.cancel.queue")
public class CancelConsumer {private final OrderService orderService;@RabbitHandlerpublic void handle(Long orderId) {Order order = orderService.find(orderId);if (order != null && order.getStatus() == OrderStatus.PENDING) {orderService.cancel(orderId);}}
}

4. 优缺点

• ✅ 实时性好（秒级）；支持分布式；消息持久化
• ❌ 需要 RabbitMQ；链路更长

5. 适用场景

中高并发，需秒级取消，已用 MQ 或愿意引入 MQ。

---

五、方案 3：Redis Keyspace 过期事件

1. 思路

以 order:{id} 作为 key，30 min TTL；Redis 键过期时推送事件；应用监听后取消订单。

2. Redis 配置

# redis.conf
notify-keyspace-events Ex

或 CLI：

CONFIG SET notify-keyspace-events Ex

3. 代码实现

3.1 订单创建时写 Redis

@Service
public class OrderService {private final StringRedisTemplate redisTemplate;public void createOrder(Order order) {orderMapper.insert(order);// value 随意，这里用 idredisTemplate.opsForValue().set("order:" + order.getId(),String.valueOf(order.getId()),Duration.ofMinutes(30));}
}

3.2 监听过期事件

@Configuration
public class RedisListenerConfig {@Beanpublic RedisMessageListenerContainer container(RedisConnectionFactory cf) {RedisMessageListenerContainer container = new RedisMessageListenerContainer();container.setConnectionFactory(cf);container.addMessageListener((message, pattern) -> {String key = message.toString();if (key.startsWith("order:")) {String orderId = key.substring(6);// 幂等取消orderService.cancelIfUnpaid(Long.valueOf(orderId));}},new PatternTopic("__keyevent@*__:expired"));return container;}
}

4. 幂等 & 可靠性

• 幂等：取消 SQL 加状态条件 WHERE status = PENDING。
• 可靠性：Redis 重启会丢失未过期 key，需 兜底定时任务（方案 1）双保险。

5. 优缺点

• ✅ 实时性高，组件少
• ❌ Redis 重启可能丢事件；需处理幂等

6. 适用场景

已用 Redis，订单量中等，能接受极低概率漏单。

---

六、3 种方案对比与选型

维度	定时任务	RabbitMQ 延迟队列	Redis 过期事件
实时性	分钟级	秒级	秒级
吞吐量	低	高	中
额外组件	无	RabbitMQ	Redis
可靠性	高	高	中（需兜底）
实现复杂度	★☆☆	★★☆	★★☆
推荐场景	小流量、兜底	高并发、已用 MQ	已用 Redis、中等并发

建议：

1. 小项目 → 定时任务即可；
2. 大流量 → 延迟队列；
3. 已用 Redis → 过期事件 + 定时任务兜底双保险。

---

七、灰度 & 监控

• 灰度发布：按用户尾号或城市分批切换方案。
• 监控指标：
  • 取消成功率
  • MQ 消息积压
  • Redis 过期 QPS
  • 定时任务扫描耗时

---

八、小结

一句话总结
定时任务 简单但慢；延迟队列 实时但重；Redis 过期 轻量但需兜底。

在实际落地中，可以 并行运行 两种方案（如延迟队列 + 兜底定时任务），通过配置开关灵活切换，确保业务永远在线。祝你的订单永不超卖！