国内很多团队对 PHP 的定位就是“写网页、出接口”，一说到后台任务、消息队列、分布式调度，第一反应就是上 Java、Go、Python。但实际上，只要你对 PHP 的 CLI 模式、进程模型和选型思路有足够理解，完全可以用纯 PHP 撑起一套稳定、可水平扩展的分布式任务调度系统。这篇文章我会从实际项目出发，讲清楚为什么 PHP 能做、怎么做、有哪些坑，以及一套可以直接抄作业的最小实现方案。
这套方案的核心是把“调度”和“执行”拆开：调度中心只负责任务分发和状态记录，Worker 进程负责具体干活，中间通过 Redis 队列解耦。适合的场景比如批量邮件发送、Excel 导出、图片压缩、第三方 API 数据同步、定时报表生成等，这些都是我在生产环境里实际跑过的任务类型。如果你正准备给 PHP 项目加一套后台任务系统，或者已经被 cron 单机瓶颈卡住了，这篇文章应该能帮你省不少时间。
1. 为什么 PHP 做分布式任务调度会被低估
1.1 PHP 写任务调度的先天条件没你想的那么差
先说结论：PHP 在任务调度领域被低估，主要是因为大多数开发者只在 Web 请求生命周期里用过它。你写一个index.php，从接收请求到输出响应，整个过程可能不到 100 毫秒，然后进程就被回收了。但 PHP 的 CLI 模式完全是另一套玩法：脚本可以长时间驻留内存、可以主动销毁变量、可以注册信号处理器、可以 fork 子进程。换句话说，PHP 绝不仅仅是一个“请求-响应”语言，它完全具备承担后台常驻任务的执行能力。
我在早期做任务系统时，也一度想引入 Go 或 Python 重写整个调度模块。后来细想，团队里全是 PHP 工程师，业务逻辑已经全部用 PHP 写好了，再去搞一套多语言混编，光是维护成本就够受的。真正的理由是：任务调度的核心复杂度根本不在语言，而在架构、队列设计、失败重试和并发控制，这些 PHP 只要有对应的扩展就能做到。你缺的不是语言能力，而是工程经验。
当然，我也不是说 PHP 就适合所有调度场景，它有不适合的地方。比如对 CPU 密集型的图像识别、大规模数值计算，PHP 的效率确实不高，这种情况老老实实把任务丢给更合适的工具链更明智。但如果你只是需要一套可靠的任务分发和执行框架，PHP 完全可以胜任，而且和现有业务代码的耦合度极低。
1.2 单机 cron 的瓶颈到底卡在哪里
大部分项目最开始都会用 cron 定时跑脚本。cron 本身很稳定，但它有天然的架构限制。最直接的痛点是：cron 只能在单台服务器上运行，一旦脚本执行时间过长、任务堆积，或者服务器宕机，整个任务系统就瘫痪了。你可能曾经遇到过这样的情况：每天早上 9 点的数据统计任务，执行到一半进程被系统 OOM kill 了，然后你一整天看到的报表都是缺数据的，直到第二天才能补上。
另一个隐藏很深的问题是 cron 的并发控制几乎为零。cron 到点就会触发，它不管你上一个实例是否还在运行。如果你的脚本耗时超过调度周期，比如每分钟跑一次、但脚本要跑两分钟，最终会有两个实例同时在跑，轻则数据重复计算，重则数据库锁竞争、连接数被打满。我见过一个团队就是因为这个原因，凌晨的批量任务重复执行，把一张千万级流水表更新了两遍，修复数据花了两天。
cron 也不适合做“按需调度”。你有一个任务需要在用户点击后 10 秒内执行，但 cron 的最小粒度一般就是每分钟，这中间的等待时间浪费得毫无意义。更重要的是，cron 没有失败重试机制，没有任务状态可视化管理，没有横向扩容的可能性。这些痛点单拎出来每一个都不致命，但叠在一起就会让你的业务越来越脆弱。这也是分布式任务调度系统出现的根本理由。
2. 分布式任务调度的架构与核心选型
2.1 队列 + Worker：最朴素也最可靠的分布式模型
分布式任务调度不是玄学，它的核心模型其实就三样东西：任务生产者、任务队列、任务消费者。生产者负责把任务描述成一条消息，比如一个 JSON 字符串，包含任务类型、参数、优先级、超时时间等；任务队列负责存储这些消息，并保证消息的有序性和可用性；消费者（也叫 Worker）从队列里拿一个任务，执行它，执行完成后告诉队列“这个任务我处理完了”。
这个模型之所以是分布式，是因为生产者和消费者都可以横向扩展。今天你的业务量小，一台服务器上跑 3 个 Worker 就够了；明天流量上来了，你再往服务器集群里加 5 个 Worker 进程，不需要改任何业务代码，只需要让它们连接同一个队列服务。这个过程就是所谓的“水平扩容”，相比单机 cron 的“垂直堆配置”要优雅得多。
我在设计这套系统时的核心选择是“用 Redis 做任务队列”。有人可能会问，为什么不用 RabbitMQ、Kafka？这是一个经典的选型问题。我的理由不是 Redis 比它们强，而是 Redis 对于一个纯 PHP 技术栈的团队来说，通常是运维成本最低、使用最熟练的基础组件。绝大多数 PHP 项目中，Redis 已经存在，你不需要新引入一套中间件，也不需要招聘一个专门的运维去维护 Kafka 集群。当你的任务量没有到达每秒数万级的时候，Redis 的 LPUSH + BRPOP 组合已经完全够用。
2.2 为什么是 Redis 而不是 MySQL 或 Kafka
先说说为什么不是 MySQL。很多人初期会把任务放到数据库表里，这个方案能跑，但它扛不住高频读写。任务队列的特点是高频出队入队，每个任务至少要写两次数据库（入队一次、状态更新一次），再加上失败重试和超时检测，数据库的压力会非常大。更重要的是，MySQL 的 SELECT ... FOR UPDATE SKIP LOCKED 做队列取任务在低并发下可行，但一旦多个 Worker 并发抢任务，锁竞争和死锁问题会让人崩溃。Redis 的 BRPOP 是原子的，多个 Worker 同时阻塞读取，每条消息只会被一个 Worker 拿走的语义是天然的，不需要你自己处理竞争。
再说说为什么不是 Kafka。Kafka 的优势在于削峰填谷、数据持久化和高吞吐，但它有一个关键特性是消费组里的消息可以被重复消费，这对流式计算是好事，对任务调度却是灾难。任务调度系统要求“一个任务必须只被一个消费者执行一次”，如果执行失败，也要有明确的重试策略，这就要求消费者能够确认消息处理成功（ACK），而 Kafka 的 offset 提交机制做任务级 ACK 其实是不顺畅的。Redis 用一个简单的 LPUSH/BRPOP 加一个额外的“处理中”队列就可以完美模拟 ACK 机制，代码量很少，还容易理解。
当然，Redis 方案也有短板。如果你的任务量真的到了百万级每天，或者你需要消息不丢失、需要复杂路由，Redis 的持久化能力和队列能力就不够看了，这时候换 RabbitMQ 甚至 Pulsar 是更合理的选择。但很多项目的问题不是选型太保守，而是阶段没到就盲目上重型中间件，把简单问题复杂化了。我的原则是：团队熟悉什么、运维能顶住什么，就先用什么，先跑通业务，性能出现瓶颈再迁移。
3. 一套可以直接抄作业的 PHP 实现方案
3.1 任务定义与入队接口
如果你准备自己写一套 PHP 任务调度系统，最好先做任务抽象。一个任务在队列里应该是一个可序列化的结构体，至少要包含：任务名称（task）、任务参数（params）、尝试次数（attempts）、最大重试次数（max_attempts）、超时时间（timeout）、创建时间（created_at）。我习惯直接用 JSON 字符串往 Redis 里推，不做 PHP 对象序列化，原因是队列消息可能被非 PHP 服务消费，JSON 是通用语言，而且排查问题的时候可以直接看队列内容。
任务入队的核心就一条命令：LPUSH task_queue $json。这里的task_queue是队列的 key，我把不同类型的任务混在一个队列里，Worker 拿到消息后再根据task字段分发。你也可以按任务类型拆成多个队列，比如queue:email、queue:export，这种方式的好处是你可以为不同类型的任务启动独立的 Worker 组，避免大量慢任务阻塞快任务的处理。我两种方案都用过，小团队建议先一刀切用单队列，复杂了再拆。
下面是我的核心入队示例，代码刻意保持简单，方便你改造：
<?php // enqueue.php —— 任务入队工具类 class TaskDispatcher { private Redis $redis; public function __construct(Redis $redis) { $this->redis = $redis; } /** * 投递一个任务 * * @param string $taskName 任务名称 * @param array $params 任务参数 * @param int $delay 延迟执行秒数 */ public function dispatch(string $taskName, array $params = [], int $delay = 0): string { $taskId = uniqid('task_', true); $payload = json_encode([ 'id' => $taskId, 'task' => $taskName, 'params' => $params, 'attempts' => 0, 'max_attempt'=> 3, 'timeout' => 300, 'created_at' => time(), 'available_at' => time() + $delay, ], JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES); if ($delay > 0) { // 延迟任务先用 zset 暂存，到期再转移到队列 $this->redis->zAdd('task:delayed', time() + $delay, $payload); } else { $this->redis->lPush('task:queue', $payload); } return $taskId; } }3.2 Worker 核心循环：BRPOP 轮询与业务分发
Worker 是执行任务的关键角色，一个 Worker 本质上就是一个常驻内存的 PHP CLI 进程。这个进程要做的事情是：循环阻塞读取队列消息、解析消息、根据任务名分发到对应的处理类、执行成功后记录完成状态、执行失败时决定是否重试。
这里最核心的一条命令是BRPOP task:queue 30，其中30是阻塞超时秒数。BRPOP 会原子地从队列右侧取出一个元素，如果队列为空，它会阻塞等待，直到有新消息进入或者超时。使用 BRPOP 而不是 LPOP + sleep 的好处很明显：消息到达之后 Worker 几乎是即时被唤醒的，没有轮询延迟；同时 Redis 在阻塞期间不消耗 CPU，你不会因为启动了几十个 Worker 就把服务器负载打上去。
实际开发中我最开始犯过一个错误：在 Worker 里直接使用单进程顺序处理任务。这种方案在任务量极小的时候看起来没问题，但一旦某个任务执行时间比较长，比如一次导出包含 10 万条数据，后边的所有任务都要排队等待，造成明显的“队头阻塞”。后来我在 Worker 里集成了pcntl_fork，每个任务单独 fork 一个子进程去执行，父进程负责接收新任务和回收子进程，这样单个 Worker 就能并发处理多个任务了。当然 fork 的开销不能忽略，任务平均耗时低于 50 毫秒的场景，多进程反而会拖慢吞吐，你要结合实际业务衡量。
下面是 Worker 的核心骨架，没有做异常兜底，先让你看清主流程：
<?php // worker.php —— 后台消费进程 require __DIR__ . '/vendor/autoload.php'; $redis = new Redis(); $redis->connect('127.0.0.1', 6379); echo "Worker 启动，进程ID: " . getmypid() . PHP_EOL; while (true) { try { // 阻塞读取队列，超时30秒 $raw = $redis->brPop('task:queue', 30); if (empty($raw)) { continue; } $task = json_decode($raw[1], true); if (json_last_error() !== JSON_ERROR_NONE) { // 入队的消息不是合法 JSON，直接丢弃并记录日志 $redis->rPush('task:dead', $raw[1]); continue; } // 调用具体的任务处理器 $handler = TaskRegistry::getHandler($task['task']); if (!$handler) { $redis->rPush('task:dead', $raw[1]); continue; } $result = $handler->handle($task['params']); // 执行成功后确认任务 if ($result === true) { $redis->rPush('task:success', json_encode($task)); } else { // 业务上认为失败，走重试逻辑 retryOrFail($redis, $task); } } catch (Throwable $e) { // 记录异常，避免循环崩溃 $redis->rPush('task:error', json_encode([ 'message' => $e->getMessage(), 'trace' => $e->getTraceAsString(), ])); sleep(1); } }注意：
brPop返回的是一个数组，$raw[0]是队列名称，$raw[1]是弹出的消息内容。很多新手第一次用会直接拿$raw去解析，导致 JSON 解析失败，我当时也在这上面花了不少时间。
3.3 失败重试、ACK 与防重复执行的细节机制
任务调度系统光有“分发-执行”是不够的，真正决定系统可靠性的，是失败重试和防重复机制。我们在生产环境总结出来的铁律是：任务可以失败，但不能丢；任务可以重复执行，但必须有幂等保障。
先讲失败重试。任务执行失败的常规处理流程是：记录当前尝试次数，如果没超过最大重试次数，把任务重新放回队列；如果已经达到上限，转入死信队列。这里有一个关键设计，就是重试不能无条件立即进行，否则会导致“失败风暴”——比如第三方 API 挂了，你这里 100 个任务同时重试，等于瞬间打爆对方服务。我的做法是采用指数退避，第一次重试延迟 5 秒，第二次 30 秒，第三次 120 秒，这个延迟可以用 Redis 的 ZSET 存储，扫描到期任务再转移到工作队列。这个逻辑实现起来不复杂，但能让你在高峰期少接很多报警电话。
再讲防重复。BRPOP 本身能保证一条消息不会被两个 Worker 同时取走，但不能保证 Worker 在执行过程中宕机后消息不丢失。如果 Worker 取走任务后还没执行完就挂了，这个任务实际上已经出队了，如果没有额外机制，任务就丢了。所以在生产环境我会引入另一个队列task:processing，Worker 取出任务后先挪到处理中队列，执行成功后再从处理中队列删除。如果 Worker 进程崩溃，启动一个恢复程序扫描task:processing中停留超过 N 秒的任务，把它重新放回工作队列。这个机制类似 RabbitMQ 里的 manual ACK，属于任务系统的“保底策略”，强烈建议加上。
关于幂等，这里多说两句。你无法保证调度系统完全不重复，尤其是网络抖动或者 Worker 重启时，同一个任务可能被执行两次。所以在业务处理器里面一定要做幂等控制，最简单的方案是给任务参数里带一个业务主键，执行前用 Redis 的SETNX抢锁，抢到锁才继续执行。举个例子：同步一笔订单数据，你可以用订单号 + 同步任务作为锁的 key，SETNX成功表示本次执行有权处理，失败则说明有另一个 Worker 正在处理同一个订单，直接跳过。没有这一层，系统在极端情况下给你跑出重复数据，排查起来会让你怀疑人生。
4. 生产环境实战：让系统从“能用”变成“可靠”
4.1 优雅退出与信号处理：别用 kill -9 硬杀 Worker
Worker 进程是常驻进程，所以你一定会遇到一个问题：上线新代码的时候怎么重启 Worker？直接kill -9杀进程当然能解决问题，但粗暴杀死进程可能会导致正在执行的任务中途夭折，占用的数据库连接和文件句柄没有机会释放。更稳妥的做法是给 Worker 增加信号处理，让它“优雅地退出”。
PHP 的pcntl_signal函数可以捕获 SIGTERM 和 SIGINT 信号。一个常见的优雅退出流程是：进程收到退出信号后，先设置一个$shutdown = true的标志位，然后在主循环的每一轮检查这个标志位，处理完当前正在执行的任务后再退出循环。这里有一个细节，如果当前任务是长任务，比如数据库备份，可能运行十几分钟，你不能在收到信号后就立刻中断它，但又不能无限等。我的处理办法是给任务执行加一个最大等待时间，收到信号后最多再等 5 秒，如果任务还没结束就直接终止子进程。
还有一个很多人忽略的问题：用 Docker 部署 Worker 时，容器的主进程 PID 1 比较特殊，默认不会转发 SIGTERM 给子进程。你可能在宿主机上执行docker stop，发现容器半天停不下来，最终超时被强制 SIGKILL。解决方案是在容器启动脚本里加一个trap或者用 supervisor 托管，把 PID 1 换成能正确处理信号的进程。我踩过这个坑之后，所有 PHP Worker 容器统一改用s6-overlay做进程托管，重启速度立竿见影地变快了。
4.2 心跳、健康检查与任务监控
分布式系统的另一个必修课是监控。你可能有 20 台服务器在跑任务，某台机器网络出了问题导致 Worker 掉了，如果你没有监控，可能要等业务方反馈“任务怎么没跑”才知道。我建议每个 Worker 进程在启动时向 Redis 写入一条心跳记录，每隔 10 秒更新一次，内容包含进程 ID、服务器 IP、启动时间、最近一次处理任务的时间、累计处理数。然后写一个简单的监控脚本定期检查心跳记录的更新时间，超过 30 秒没更新就认为 Worker 异常，通过钉钉或企业微信机器人发告警。
任务级别的监控同样重要。我为系统里每个任务都打了几个关键指标：任务入队数、消费成功数、消费失败数、队列积压数、平均执行耗时。这些数据不需要引入大数据组件，直接计数到 Redis 里就行，用INCR统计总量，用 hash 存指标项。每天拉一条数据，就能看到整个系统的吞吐趋势和瓶颈。尤其是平均执行耗时，如果某个 Worker 的平均耗时持续走高，多半是任务代码里有性能问题，比如循环里查数据库，及时优化能避免一次线上事故。
健康检查方面，我最后定型的方案是一个独立 PHP 脚本，周期性执行三类检查：Redis 连接是否正常、队列积压数量是否超过阈值、是否有 Worker 心跳超时。任何一项异常就告警。这个脚本本身部署在单独的调度器上，不依赖业务 Worker，保证监控链路独立可靠。
4.3 日志规范：JSon 结构化输出是排查问题的最后一道防线
任务系统的日志和 Web 请求日志不太一样，Web 请求的日志可以通过 Nginx 访问日志串联，而任务往往是异步的，单个任务可能跨越多个进程，甚至多台服务器，传统的文本日志很难把上下文串起来。强烈建议从第一天开始就用 JSON 结构化日志，每条日志里至少包含任务 ID、任务名称、执行机器、进程 ID、时间戳和日志等级。
我见过一个排查到深夜的真实场景：某个同步任务每天凌晨偶尔失败，但没有记录任务 ID，只能翻 100 万条日志按时间慢慢比对，效率极低。后来我重构了日志系统，所有 Worker 写日志时自动带上任务 ID，定位问题的耗时从小时级降到了分钟级。
实现也很简单，写一个 Logger 基类，内部封装json_encode，调用时传入上下文数组，输出格式大概是：
{"time":"2024-06-18 02:15:30","level":"error","task_id":"task_66x","task_name":"sync_order","server":"192.168.1.10","pid":12345,"message":"API reuqest timeout"}注意所有异步任务的日志，最好统一写到同一个目录，并按日期分文件，然后交给日志收集系统集中处理。如果团队规模不大没有日志平台，至少保证每个 Worker 进程把错误日志中带进程 ID，方便你登录服务器后用grep快速锁定问题进程。
5. 从“单 Worker 集群”升级：调度一致性、定时任务与容量规划
5.1 多 Worker 实例下的调度一致性：保证不会重复执行
当你把 Worker 从 1 个扩展到 10 个之后，第一个需要解决的是竞态条件。Redis 的 BRPOP 本身是原子的，多个 Worker 同时 BRPOP 同一条消息，Redis 服务器会一个一个地响应，因此不会出现“两个 Worker 拿到同一条消息”的情况。问题出在更上游：任务入队和业务操作之间可能存在竞态。比如你的业务代码里先判断某个状态，再入队，如果两个请求同时进入了这个判断区间，就可能产生两个重复的任务。
要解决这类问题，一般是在入队前做一次去重。Redis 的SETNX是天然的去重工具，你可以为每个任务生成一个唯一的业务 ID，入队前先SETNX task:unique:$bizId 1，如果返回 1 表示任务尚未存在，可以进行入队；如果返回 0，说明已经有一个同 ID 的任务在队列里，直接丢弃。需要注意这个去重 key 要设置过期时间，比如任务最大重试周期结束后自动清理，否则 Redis 里会积攒大量无用 key。
另外还有一个调度一致性相关的细节：多个 Worker 同时消费同一个队列时，某个 Worker 可能因为网络原因从队列里取走任务，但还没来得及处理就断线了。这个任务既不在工作队列里，也不在已经处理成功的列表里，成了“空中任务”。前面提到的task:processing队列在这里就能发挥作用，配合一个恢复扫描器，定期把卡住的任务捞回来重新入队，可以最大化保证系统的高可用。
5.2 定时任务的分布式实现：用 PHP 写一个轻量级调度中心
单机 cron 无法分布式执行，那分布式系统里的“每天凌晨两点跑一次报表”怎么实现？答案是引入一个调度中心。调度中心本身也是一个常驻 PHP 进程，但它不执行具体任务，只负责“到点了，把任务投递到 Redis 队列”。Worker 不知道也不关心任务是不是定时触发的，它只管消费队列。
调度中心的核心是一张任务计划表。你可以把每个定时任务的名称、cron 表达式、最近执行时间、下次执行时间存在 MySQL 里。调度器每 30 秒扫描一次这张表，找出所有“下次执行时间 ≤ 当前时间”的任务，把它们投递到队列，然后更新最近执行时间和下次执行时间。这里的关键是要防止多个调度中心实例同时触发同一个任务，如果调度中心部署了两个节点，它们在同一个时间点扫描同一张表，就可能重复入队。
我的做法是使用 MySQL 的GET_LOCK或者 Redis 的分布式锁来确保同一时刻只有一个调度器实例在跑。调度器启动后，先去获取一个 key 为scheduler:lock的锁，拿到锁的实例负责扫描和投递，另外一个实例处于等待状态。如果持锁的实例挂了，锁超时自动释放，另一个实例就接管调度，实现故障转移。这套方案我不建议一开始就搞得很重，单机单调度器就够用，多节点调度器留到确实需要高可用的时候再加。
5.3 容量规划：一个 Worker 到底能跑多少任务，怎么估算？
分布式系统最怕拍脑袋扩容。我见过有人一上来就开 50 个 Worker，结果任务还没多少，Redis 连接数先爆了。那么怎么估算一个 Worker 能承载多少任务呢？公式很简单：单个 Worker 的并发处理数 = 每个进程每秒能处理的任务数 × 进程数。假设你的任务是调用第三方 API，平均耗时 200 毫秒，单进程单线程模式下每秒能处理 5 个；如果每个 Worker fork 5 个子进程，理论吞吐就是每秒 25 个，一天约 216 万个。实际情况还要考虑系统调用、日志写入、Redis 网络开销，按照理论值的 30-50% 预估比较稳妥。
另外要关注的是 Redis 的内存和连接数。每个任务在 Redis 里是一条 JSON 字符串，假设平均 500 字节，100 万个任务也就是 500MB，这个量级对 Redis 来说是毛毛雨。连接数方面，一个 Worker 维持 1 个 Redis 连接，50 个 Worker 就是 50 个连接，Redis 默认支持 1 万个连接，绰绰有余。但如果你的持久化策略是 AOF 并且每秒同步一次，任务量大的时候 Redis 的写压力会显著增加，建议一开始就配置好 RDB + AOF 混合持久化，并设置合理的maxmemory和maxmemory-policy。
6. 常见问题与排查实录
6.1 队列积压与消费速度上不去怎么办
最典型的场景是某个时间段入队速度激增，Worker 的处理速度跟不上，马上队列积压就有几十万条任务，所有任务延迟处理。遇到这个问题，第一反应不是加机器，而是先看任务消费速度曲线，定位瓶颈。
我遇到过一个真实案例：Worker 进程数是 10 个，每个 Worker 里 fork 5 个子进程，理论并发 50，但队列还是积压。后来发现原因是一个任务处理器里在 for 循环内查询 MySQL，对商品 SKU 表做单条更新，处理速度只有每秒 3 条。优化方式是把单条更新改成批量 UPDATE，吞吐瞬间提升了 10 倍。这说明加机器只是治标，优化业务代码里低效的 SQL 才是治本。
如果确认业务代码已经优化充分，队列还是积压，那就需要扩容 Worker，要把 Worker 扩展到其他机器上，也要注意机器之间的配置均衡。同时给每个 Worker 增加一个队列长度指标上报，当积压长度超过 N 的时候自动增加 Worker 实例，低于阈值就回收多余的进程，把资源降下来省成本。
6.2 任务丢失和重复执行的排查方法
任务丢失和重复是调度系统最让人头疼的两个问题。丢失的常见原因有三个：一是 Redis 持久化策略配置不当，宕机后队列数据丢失；二是 Worker 取走任务后直接崩溃，任务没有 ACK；三是入队时 JSON 序列化失败但异常被吞掉了。排查时先看 Redis 有没有开持久化，再看task:processing队列有没有堆积，最后看业务日志里有没有序列化异常。
重复执行的常见原因则有两个：一是失败重试时消息被重新放回队列，但业务逻辑没有做好幂等；二是调度中心重复调度。对于重试导致的重复，解决方法是加入业务主键锁，用SETNX防止并发执行；对于调度中心引起的重复，检查分布式锁是否正常释放，以及 MySQL 任务计划表的更新时间是否有脏读。
分享一个我实际用过的排查技巧：给每个任务定义唯一 ID 之后，在所有关键节点（入队、出队、执行成功、失败重试）都打印包含任务 ID 的日志。如果一个任务在系统里丢失了，你可以把任务 ID 作为关键词在日志平台里搜一圈，马上就能定位它在哪个环节出了问题。没有这个习惯，排查分布式问题就像在黑暗里找钥匙，效率极低。
6.3 Worker 进程内存泄漏与 CPU 飙升的应对策略
PHP 作为常驻进程运行，你最需要担心的就是内存泄漏。虽然 PHP 不像 C/C++ 那样有显式内存管理，但长驻进程中变量释放不及时、循环引用累计，最终一样可能导致 OOM。我的经验是每一个 Worker 在处理完一个任务后主动执行一次gc_collect_cycles()，并且在主循环里加上内存监控，当进程占用超过 128MB 时，处理完当前任务后主动退出，由 supervisor 拉起一个新进程。这种“内存用完就重启”的策略虽然简单粗暴，但非常有效，能让系统的稳定性提高一个档次。
另一个容易踩的坑是 CPU 飙升。一种常见原因是代码里写了死循环，比如误用了while(true)而没有正确退出条件；另一种原因是 BRPOP 超时时间设置成 0，任务队列是空的，Worker 就成为一个纯忙等的进程，飞一样地消耗 CPU。解决办法是把超时时间设置为大于 0，比如 5-30 秒，或者直接改成BRPOP，这样在队列为空的时候进程会进入阻塞状态，不消耗 CPU。
最后说说僵尸进程。如果你在 Worker 里用了pcntl_fork，却忘记调用pcntl_waitpid去回收子进程，系统里会积累一大堆僵尸进程。它们本身不消耗 CPU 和内存，但会占满进程表，导致无法创建新进程，也需要通过定时清理任务来回收。这里有个小技巧，每次循环开始先调用pcntl_waitpid(-1, $status, WNOHANG)回收已经结束的子进程，这是最低成本的防僵尸方案。
我个人实际使用这套 PHP 分布式任务调度方案已经三年多时间，从一开始的单机单进程，到现在的容器化多节点部署，中间踩过的坑、加过的补丁不少，但整体框架始终稳定。最后想说的是，不要因为 PHP 被贴上“web 专用”的标签就怀疑它，技术选型的关键始终是团队能力和业务场景，只要架构思路对，PHP 完全能扛起后台任务这片天。如果后续业务量继续上涨，这套基于 Redis 的方案也可以平滑迁移到 RabbitMQ 或者其他的消息中间件，核心模型不会变，迁移成本可控。希望这篇文章能帮各位少走一些弯路。
