PHP 定时任务重复启动怎么处理：flock 文件锁、PID 记录与超时回收

凌晨两点的订单同步本该只跑一次，监控里却出现了两条相隔十几秒的同名日志：两边都读到了同一批待同步记录。很多 PHP 定时任务的重叠不是业务代码写错，而是上一轮还没收尾，下一轮已经被 Crontab 拉起。这里别急着加一个“正在运行”的文本标记，先把互斥、任务身份和人工判断拆开。

定时任务重复启动的常见场景下，优先通过非阻塞flock做入口互斥，结合锁文件内的元信息做状态观测，不要依赖单纯的文件存在判断、PID校验自行清理锁文件，用业务幂等兜底锁边界之外的异常。

为什么“每分钟跑一次”会变成并发写入

假设 sync_orders.php 每分钟启动一次。平时一次同步只用 8 秒，大家很容易默认它永远能在下一分钟到来前结束。某天第三方接口抖动，单批请求退避到 95 秒；下一次调度照常启动，新旧两个进程同时把 sync_status=0 的订单取走，重复请求和状态覆盖就出现了。

这种情况越来越常见：任务从“每天清一次临时表”慢慢长成了同步、推送、补偿和统计的组合。互斥锁解决的是同一时刻谁有资格进入临界区，不解决接口慢、数据幂等、跨机器调度等全部问题。把它当作第一道闸门更合适。

先用非阻塞 flock 把重叠运行挡在入口外

文件锁需要在任务存活期间一直持有文件句柄。下面的例子把锁放到应用自己的可写目录，不要放在会被发布脚本整体清理的临时目录。抢锁失败时返回正常状态即可；对调度器来说，这一轮没有做业务写入，但已经留下了可追踪的原因。

 $job,
    'pid' => $pid,
    'started_at' => $startedAt,
], JSON_UNESCAPED_UNICODE) . PHP_EOL);
fflush($handle);

try {
    syncPendingOrders();
    error_log(sprintf('[%s] done pid=%d', $job, $pid));
} finally {
    flock($handle, LOCK_UN);
    fclose($handle);
}

这里的关键不是 .lock 文件会不会留下。正常结束后文件仍可能存在，但内核锁已经释放；下一轮是否能拿到锁，才是互斥状态。只检查 file_exists() 会把“历史文件还在”误判成“任务仍在跑”。

锁冲突日志要能回答三个问题

只打印“任务已跳过”不够。建议在成功持锁时写入元信息，锁冲突时读取一份快照并把它附到日志里。这样值班排查能知道是 sync_orders 真的耗时变长，还是有人手工拉起了第二个进程。

PID 记录适合观察，不要把它当成第二把锁

PID 能帮助人判断，但它不应该代替 flock。进程号可能被系统复用，容器重启后旧 PID 更没有意义；用“PID 文件存在”来阻止启动，反而容易留下永久卡死的假象。更稳妥的分工是：文件锁负责实时排他，PID 与开始时间负责告警上下文。

任务进入业务逻辑前可以写一条结构化日志，结束时再写耗时。若持续时间超过任务间隔的两倍，监控发出提醒；这条提醒不是让脚本自行删除锁，而是提示人检查慢点落在第三方接口、数据库事务还是积压数据量。

$begin = hrtime(true);
try {
    syncPendingOrders();
} finally {
    $durationMs = (hrtime(true) - $begin) / 1_000_000;
    error_log(json_encode([
        'job' => 'sync_orders',
        'pid' => getmypid(),
        'duration_ms' => round($durationMs),
        'result' => 'finished',
    ], JSON_UNESCAPED_UNICODE));
}

超过预期时，按“锁状态—进程—业务批次”处理

长时间持锁并不等于故障。大批量补偿可能正正常推进；反过来，锁能拿到也不证明上一批没有留下半完成数据。处理时先看锁文件中的任务信息，再核对该 PID 是否存在，最后回到订单批次或游标的位置确认业务边界。

1. 锁冲突刚发生且持锁时间较短：记录跳过次数，等待下一轮，避免额外启动补偿脚本。
2. 持锁时间超过阈值但 PID 仍存在：查看最近日志、接口重试数和当前批次游标；先别急着停止进程。
3. 锁文件有旧信息而锁已可获得：说明锁早已释放，刷新元信息后正常运行，不要因为旧文件中止任务。
4. 业务批次被中断：根据已落库的 batch_id 或游标补偿，业务写入仍需有唯一键或幂等标记兜底。

哪些场景不应只靠本地文件锁

flock 的边界很清楚：它适合一台机器上的多个 PHP 进程争夺同一项任务。当任务被多个容器、多个 Web 节点或两套调度系统同时触发时，各自的本地文件互相看不见。此时要把互斥点放到共享介质，例如数据库唯一记录、Redis 分布式锁，或调度平台本身的并发策略。

选择共享锁时，仍保留业务幂等。锁可能因为网络抖动、租约到期或人为操作失去保护；订单同步、发券、退款这类动作更应该用唯一业务键抵住重复写入。锁负责降低并发概率，幂等负责守住最终结果，这两个职责不要混在一起。

上线前的最小检查清单

• 确认锁文件目录不会被发布、清理任务或容器启动脚本随意删除。
• 用两次相隔几秒的手工启动复现锁冲突，确认第二次只留下跳过日志，不进入业务写入。
• 让第一轮故意停留一小段时间，检查 PID、开始时间和耗时字段是否完整。
• 确认业务表有唯一约束、状态机或批次标记，避免锁失效时造成重复结果。
• 跨机器部署时，明确改用哪一种共享互斥机制，并写出失锁后的补偿路径。

相关问题

flock 释放后锁文件为什么还在？

锁和文件是两回事。进程关闭句柄或解锁后，其他进程可以继续获得锁；是否删除文件只是清洁策略，不应用来判断任务是否运行。

抢不到 flock 时应该排队等待吗？

定时同步通常更适合非阻塞跳过，因为排队会让落后的任务连续堆积。确实不能漏跑的场景要改成队列或明确的补偿机制。

PHP 任务异常退出会不会留下死锁？

文件描述符随进程结束被系统关闭，关联的文件锁会释放。需要额外排查的是半完成业务数据，而不是盲目删除锁文件。

Redis 锁能完全替代业务幂等吗？

不能。共享锁解决多节点争抢，业务幂等处理重复请求、超时重试和边界故障；涉及资金或库存时，两层保护都要保留。

把互斥做成可观察的运行规则

一个小小的 flock 能挡住最常见的重复启动，但真正让定时任务可维护的是可观察性：谁在运行、运行了多久、处理到哪个批次、冲突发生了几次。先用本地锁把入口收紧，再用日志和业务幂等补齐边界，后续迁移到多节点调度时也不会推倒重来。