本文目录导读：
- 方案一：使用消息队列 + 延迟队列（最推荐，生产级）
- 方案二：定时任务（Cron）扫描数据库
- 方案三：使用 Redis 的 Key 过期回调（不推荐用于核心业务）
- 方案四：用户主动触发时检查（最不推荐，仅作为兜底）
- 生产环境建议方案组合
- 最佳实践（防坑指南）
在PHP项目中实现订单超时取消，常见且推荐的方案有以下几种，按推荐程度从高到低排列：
使用消息队列 + 延迟队列（最推荐，生产级）
这是目前最主流、最稳定的方案，利用 RabbitMQ 或 Redis 的延迟队列特性。
核心原理： 创建订单后，将订单ID和超时时间（如30分钟）发送到延迟队列,消息在指定时间后才会被消费者获取并处理。
以 Redis（Sorted Set + 定时轮询）为例：
// 1. 用户下单后，将订单信息写入 Redis 延迟队列
$orderId = 12345;
$expireTime = time() + 1800; // 30分钟后到期
$redis->zAdd('order:delay', $expireTime, $orderId);
// 2. 后台一个常驻脚本（或cron每分钟执行），轮询处理
while (true) {
// 获取当前时间之前的订单ID（即已超时的订单）
$expiredOrders = $redis->zRangeByScore('order:delay', '-inf', time());
foreach ($expiredOrders as $orderId) {
// 从队列中移除（原子操作，防止重复处理）
$removed = $redis->zRem('order:delay', $orderId);
if ($removed) {
// 执行取消订单逻辑（需要先检查订单状态，避免重复取消）
cancelOrder($orderId);
}
}
sleep(1); // 每秒轮询一次
}
优点： 精确，高并发友好，不依赖数据库压力。
缺点： 需要额外维护Redis/RabbitMQ。
定时任务（Cron）扫描数据库
简单直接，适合中小项目（订单量 < 10万/天）。
核心原理： 写一个PHP脚本，通过 cron 每隔1-2分钟执行一次,扫描订单表并取消超时订单。
代码实现：
// cron.php (每分钟执行一次)
$timeLimit = date('Y-m-d H:i:s', strtotime('-30 minutes'));
$sql = "UPDATE orders
SET status = 'cancelled',
cancel_time = NOW()
WHERE status = 'pending'
AND create_time <= '$timeLimit'";
$db->query($sql);
// 可选：记录日志
error_log("Cancelled " . $db->affectedRows() . " expired orders.");
Crontab 配置：
* * * * * /usr/bin/php /path/to/cron.php > /dev/null 2>&1
优缺点：
- ✅ 简单、无需额外组件。
- ❌ 1-2分钟延迟，高并发下数据库压力大（需加索引优化）。
- ❌ 订单量大时可能扫不完（建议加
LIMIT 1000分批处理）。
使用 Redis 的 Key 过期回调（不推荐用于核心业务）
利用 Redis keysapce notification 机制,当key过期时触发PHP回调。
原理： 下单时设置一个带过期时间的key（如order:12345）,过期时Redis通知PHP脚本执行取消。
缺点：
- Redis 过期时间不精确（实际可能延迟数秒到数分钟）。
- 如果回调失败（如进程挂了），订单永远不会被取消。
- 依赖
notify-keyspace-events Ex配置。 - 生产中很少用于核心交易，适合辅助场景。
用户主动触发时检查（最不推荐，仅作为兜底）
原理： 用户在查看订单详情、支付、或任何交互时，检查当前订单是否过期,如果过期则自动取消。
public function getOrderDetail($orderId) {
$order = $this->orderModel->find($orderId);
// 如果订单状态为 pending 且超时，立即取消
if ($order['status'] == 'pending' && $order['create_time'] < time() - 1800) {
$this->cancelOrder($orderId);
$order['status'] = 'cancelled';
}
return $order;
}
优点： 零额外成本。
缺点： 如果用户一直不访问，订单永远不会取消，不能作为主要方案，只能作为前端展示层的兜底。
生产环境建议方案组合
流量低 (电商早期):
方案一(Redis Sorted Set) + 方案二(Cron) 作为备份
流量中等 (日单10万+):
方案一(RabbitMQ延迟队列) + 方案二(仅扫描异常订单)
流量高 (电商大促):
方案一(专用延迟消息队列) + 方案四(用户端兜底)最佳实践（防坑指南）
- 状态检查：取消前务必再次检查订单状态（防重复取消）。
- 仅失效一定时间内的订单：不要
UPDATE WHERE create_time < NOW() - 30min，要限制在合理时间范围（如只取消最近7天的）。 - 索引优化：方案二中的
(status, create_time)建立复合索引。 - 幂等性：取消逻辑尽量幂等,多次执行不影响。
- 订单量突然暴增时，方案二建议加
LIMIT分批处理,避免锁表。
如果项目刚起步，建议先用 方案二（Cron扫描），快速上线，后期更换为 方案一（Redis Sorted Set）。
