不能直接用定时器轮询订单表,因高并发下轮询会压垮数据库且workerman定时器无持久化,进程重启后定时任务丢失;需结合expires_at字段、独立扫描进程、消息队列异步关单及select for update库存回滚,保障幂等与可靠性。

为什么不能直接用定时器轮询订单表
因为高并发下单时,每秒可能产生数百订单,如果用 while(true) + sleep(1) 去查数据库,不仅 CPU 持续占用,还会在高峰期把数据库查挂——尤其是 SELECT ... WHERE status = 'pending' AND created_at 这类查询缺乏有效索引时,全表扫描一上来就卡死。
Workerman 的本质是常驻内存的异步 PHP 进程,它不提供“全局定时任务”能力,也没有类似 Laravel Scheduler 那种基于 crontab 的调度器。硬塞一个死循环进去,等于放弃它的事件驱动优势,还容易因异常中断导致任务丢失。
用 Timer::add() 为每个订单单独设超时回调
这是最贴合 Workerman 设计哲学的做法:订单创建成功后,立刻调用 Timer::add() 启动一个一次性倒计时,到期触发取消逻辑。它不依赖外部调度,不扫库,不竞争锁,天然精准到秒级。
关键点:
-
Timer::add()的回调函数必须是静态方法或闭包,且不能含阻塞操作(比如同步 MySQL 查询);要用MySQLi::query()或协程 MySQL 客户端 - 订单创建和定时器注册必须在同一个进程内完成;跨进程(如多 worker)时需确保
Timer在创建订单的 worker 中注册,否则定时器不会执行 - 务必在回调中检查订单当前状态,防止用户已手动支付但定时器仍执行取消——加一句
if ($order['status'] !== 'pending') return;
示例片段:
// 订单创建成功后立即设置超时
$timeout = 30 * 60; // 30分钟
Timer::add($timeout, function () use ($order_id) {
$pdo = DB::getConnection();
$stmt = $pdo->prepare("SELECT status FROM orders WHERE id = ?");
$stmt->execute([$order_id]);
$order = $stmt->fetch();
if (!$order || $order['status'] !== 'pending') {
return;
}
// 执行取消:更新状态、释放库存、发通知...
$pdo->prepare("UPDATE orders SET status = 'cancelled' WHERE id = ?")->execute([$order_id]);
}, [], true); // 第四个参数 true 表示只执行一次
进程重启或异常退出时,未触发的定时器会丢失
Workerman 没有持久化定时器机制。一旦 worker 进程被 kill、reload 或崩溃,所有通过 Timer::add() 注册的未触发定时器全部消失——这意味着部分订单永远不会被自动取消。
必须补一层兜底:
- 数据库字段加
expires_at(datetime 类型),写入订单时就计算好超时时间 - 另起一个独立的
Worker进程(非 Web worker),每 2 分钟执行一次轻量级扫描:SELECT id FROM orders WHERE status = 'pending' AND expires_at ,只查 ID,限制 100 条,避免慢查询 - 这个扫描进程要加
daemonize = false或用 supervisord 管理,确保它永不停止
注意:扫描频率不能太密(比如设成 1 秒),否则又回到轮询老路;也不能太疏(比如 10 分钟),会导致最多延迟 10 分钟才取消,影响用户体验。
取消逻辑里别直接调用微信/支付宝关单 API
第三方关单接口有调用频控(微信是 2000 次/小时/商户号),如果多个订单超时集中在同一秒触发,极可能触发限流返回 TRADE_NOT_EXIST 或 SYSTEMERROR,而且这些错误你还不能重试——因为订单已经关过了。
正确做法是把关单请求投递到消息队列(如 Redis List 或 Kafka),由单独消费者进程串行处理,并对失败做指数退避重试。Workerman 内部不要出现任何 HTTP 同步调用。
另外,库存回滚也得注意事务隔离级别:用 SELECT ... FOR UPDATE 锁住对应 SKU 行,再更新库存,否则高并发下可能多退库存。
真正难的不是设个定时器,而是让整个链路在进程生命周期不可靠的前提下,依然保证“最多取消一次”——这需要数据库状态校验、幂等标记、异步解耦三者配合。漏掉任意一环,都会出现已支付订单被误取消,或者超时订单长期滞留 pending 状态。











