在电商、外卖、票务等系统中，订单超时未支付自动取消是一个常见的需求。
这个功能乍一看很简单，甚至很多初学者会觉得："不就是加个定时器么？" 但真到了实际工作中，细节的复杂程度往往会超乎预期。
这里我们从基础到高级，逐步分析各种实现方案，最后分享一些在生产中常见的优化技巧，希望对你会有所帮助。
1. 使用延时队列（DelayQueue）
适用场景：订单数量较少，系统并发量不高。
延时队列是Java并发包（java.util.concurrent）中的一个数据结构，专门用于处理延时任务。
订单在创建时，将其放入延时队列，并设置超时时间。
延时时间到了以后，队列会触发消费逻辑，执行取消操作。
示例代码：
import java.util.concurrent.*;
public class OrderCancelService {
private static final DelayQueue<OrderTask> delayQueue = new DelayQueue<>();
public static void main(String[] args) throws InterruptedException {
// 启动消费者线程
new Thread(() -> {
while (true) {
try {
OrderTask task = delayQueue.take(); // 获取到期任务
System.out.println("取消订单：" + task.getOrderId());
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
}).start();
// 模拟订单创建
for (int i = 1; i <= 5; i++) {
delayQueue.put(new OrderTask(i, System.currentTimeMillis() + 5000)); // 5秒后取消
System.out.println("订单" + i + "已创建");
}
}
static class OrderTask implements Delayed {
private final long expireTime;
private final int orderId;
public OrderTask(int orderId, long expireTime) {
this.orderId = orderId;
this.expireTime = expireTime;
}
public int getOrderId() {
return orderId;
}
@Override
public long getDelay(TimeUnit unit) {
return unit.convert(expireTime - System.currentTimeMillis(), TimeUnit.MILLISECONDS);
}
@Override
public int compareTo(Delayed o) {
return Long.compare(this.expireTime, ((OrderTask) o).expireTime);
}
}
}
优点：
-
实现简单，逻辑清晰。
缺点：
-
依赖内存，系统重启会丢失任务。
-
随着订单量增加，内存占用会显著上升。
2. 基于数据库轮询
适用场景：订单数量较多，但系统对实时性要求不高。
轮询是最容易想到的方案：定期扫描数据库，将超时的订单状态更新为“已取消”。
示例代码：
public void cancelExpiredOrders() {
String sql = "UPDATE orders SET status = 'CANCELLED' WHERE status = 'PENDING' AND create_time < ?";
try (Connection conn = dataSource.getConnection();
PreparedStatement ps = conn.prepareStatement(sql)) {
ps.setTimestamp(1, new Timestamp(System.currentTimeMillis() - 30 * 60 * 1000)); // 30分钟未支付取消
int affectedRows = ps.executeUpdate();
System.out.println("取消订单数量：" + affectedRows);
} catch (SQLException e) {
e.printStackTrace();
}
}
优点：
-
数据可靠性强，不依赖内存。
-
实现成本低，无需引入第三方组件。
缺点：
-
频繁扫描数据库，会带来较大的性能开销。
-
实时性较差（通常定时任务间隔为分钟级别）。
优化建议：
-
为相关字段加索引，避免全表扫描。
-
结合分表分库策略，减少单表压力。
3. 基于Redis队列
适用场景：适合对实时性有要求的中小型项目。
Redis 的 List 或 Sorted Set 数据结构非常适合用作延时任务队列。
我们可以把订单的超时时间作为 Score，订单 ID 作为 Value 存到 Redis 的 ZSet 中，定时去取出到期的订单进行取消。
例子：
public void addOrderToQueue(String orderId, long expireTime) {
jedis.zadd("order_delay_queue", expireTime, orderId);
}
public void processExpiredOrders() {
long now = System.currentTimeMillis();
Set<String> expiredOrders = jedis.zrangeByScore("order_delay_queue", 0, now);
for (String orderId : expiredOrders) {
System.out.println("取消订单：" + orderId);
jedis.zrem("order_delay_queue", orderId); // 删除已处理的订单
}
}
优点：
-
实时性高。
-
Redis 的性能优秀，延迟小。
缺点：
-
Redis 容量有限，适合中小规模任务。
-
需要额外处理 Redis 宕机或数据丢失的问题。
4. Redis Key 过期回调
适用场景：对超时事件实时性要求高，并且希望依赖 Redis 本身的特性实现简单的任务调度。
Redis 提供了 Key 的过期功能，结合 keyevent 事件通知机制，可以实现订单的自动取消逻辑。
当订单设置超时时间后，Redis 会在 Key 过期时发送通知，我们只需要订阅这个事件并进行相应的处理。
例子：
-
设置订单的过期时间：
public void setOrderWithExpiration(String orderId, long expireSeconds) {
jedis.setex("order:" + orderId, expireSeconds, "PENDING");
}
-
订阅 Redis 的过期事件：
public void subscribeToExpirationEvents() {
Jedis jedis = new Jedis("localhost");
jedis.psubscribe(new JedisPubSub() {
@Override
public void onPMessage(String pattern, String channel, String message) {
if (channel.equals("__keyevent@0__:expired")) {
System.out.println("接收到过期事件，取消订单：" + message);
// 执行取消订单的业务逻辑
}
}
}, "__keyevent@0__:expired"); // 订阅过期事件
}
优点：
-
实现简单，直接利用 Redis 的过期机制。
-
实时性高，过期事件触发后立即响应。
缺点：
-
依赖 Redis 的事件通知功能，需要开启
notify-keyspace-events配置。 -
如果 Redis 中大量使用过期 Key，可能导致性能问题。
注意事项：要使用 Key 过期事件，需要确保 Redis 配置文件中 notify-keyspace-events 的值包含 Ex。比如：
notify-keyspace-events Ex
5. 基于消息队列（如RabbitMQ）
适用场景：高并发系统，实时性要求高。
订单创建时，将订单消息发送到延迟队列（如RabbitMQ 的 x-delayed-message 插件）。
延迟时间到了以后，消息会重新投递到消费者，消费者执行取消操作。
示例代码（以RabbitMQ为例）：
public void sendOrderToDelayQueue(String orderId, long delay) {
Map<String, Object> args = new HashMap<>();
args.put("x-delayed-type", "direct");
ConnectionFactory factory = new ConnectionFactory();
try (Connection connection = factory.newConnection();
Channel channel = connection.createChannel()) {
channel.exchangeDeclare("delayed_exchange", "x-delayed-message", true, false, args);
channel.queueDeclare("delay_queue", true, false, false, null);
channel.queueBind("delay_queue", "delayed_exchange", "order.cancel");
AMQP.BasicProperties props = new AMQP.BasicProperties.Builder()
.headers(Map.of("x-delay", delay)) // 延迟时间
.build();
channel.basicPublish("delayed_exchange", "order.cancel", props, orderId.getBytes());
} catch (Exception e) {
e.printStackTrace();
}
}
优点：
-
消息队列支持分布式，高并发下表现优秀。
-
数据可靠性高，不容易丢消息。
缺点：
-
引入消息队列增加了系统复杂性。
-
需要处理队列堆积的问题。
6. 使用定时任务框架
适用场景：订单取消操作复杂，需要分布式支持。
定时任务框架，比如：Quartz、Elastic-Job，能够高效地管理任务调度，适合处理批量任务。
比如 Quartz 可以通过配置 Cron 表达式，定时执行订单取消逻辑。
示例代码：
@Scheduled(cron = "0 */5 * * * ?")
public void scanAndCancelOrders() {
System.out.println("开始扫描并取消过期订单");
// 这里调用数据库更新逻辑
}
优点：
-
成熟的调度框架支持复杂任务调度。
-
灵活性高，支持分布式扩展。
缺点：
-
对实时性支持有限。
-
框架本身较复杂。
7. 基于触发式事件流处理
适用场景：需要处理实时性较高的订单取消，同时结合复杂业务逻辑，例如根据用户行为动态调整超时时间。
可以借助事件流处理框架（如 Apache Flink 或 Spark Streaming），实时地处理订单状态，并触发超时事件。
每个订单生成后，可以作为事件流的一部分，订单未支付时通过流计算触发超时取消逻辑。
示例代码（以 Apache Flink 为例）：
DataStream<OrderEvent> orderStream = env.fromCollection(orderEvents);
orderStream
.keyBy(OrderEvent::getOrderId)
.process(new KeyedProcessFunction<String, OrderEvent, Void>() {
@Override
public void processElement(OrderEvent event, Context ctx, Collector<Void> out) throws Exception {
// 注册一个定时器
ctx.timerService().registerProcessingTimeTimer(event.getTimestamp() + 30000); // 30秒超时
}
@Override
public void onTimer(long timestamp, OnTimerContext ctx, Collector<Void> out) throws Exception {
// 定时器触发，执行订单取消逻辑
System.out.println("订单超时取消，订单ID：" + ctx.getCurrentKey());
}
});
优点：
-
实时性高，支持复杂事件处理逻辑。
-
适合动态调整超时时间，满足灵活的业务需求。
缺点：
-
引入了流计算框架，系统复杂度增加。
-
对运维要求较高。
总结
每种方案都有自己的适用场景，大家在选择的时候，记得结合业务需求、订单量、并发量来综合考虑。
如果你的项目规模较小，可以直接用延时队列或 Redis；而在大型高并发系统中，消息队列和事件流处理往往是首选。
当然，代码实现只是第一步，更重要的是在实际部署和运行中进行性能调优，保证系统的稳定性。
希望这篇文章能给大家一些启发，也欢迎讨论其他可能的实现思路！
扫一扫
2046
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
