Laravel怎么处理队列任务重试间隔_Laravel指数退避策略配置【详解】

Lara vel 的队列任务重试间隔，到底是怎么算的？这个问题往下挖，其实很多开发者都踩过坑。

先说几个核心判断：Lara vel 并不会自动给你做指数退避。对，你没听错。默认情况下，它就是固定等那么几秒。想要真正的指数退避，必须手动把 $backoff 配成数组。不然的话，哪怕你把 $tries 设成 5，每次失败后等待的秒数也是一模一样的，比如全都等 3 秒，这跟指数增长八竿子打不着。

最常见的现象就是，你盯着 php artisan queue:work 的日志，发现任务总是在相同的时间点重试，比如每 3 秒一次。但你心里预期的是 1 秒、2 秒、4 秒、8 秒这样往上翻。问题出在哪儿？

• $tries = 5 —— 这个参数只决定任务最多能被执行几次（首次执行也算在里面），它不改间隔。
• $backoff = 3（整数） —— 每次失败后固定等 3 秒，没啥好说的。
• $backoff = [1, 2, 4, 8]（数组） —— 这才是真正的指数退避。第1次失败等1秒，第2次等2秒，第3次等4秒，第4次等8秒。这里有个关键点：数组的长度必须大于等于 $tries - 1。如果数组不够长，后面的重试会用数组里最后那个值来兜底。
• 举个例子：$tries = 5，但 $backoff = [1, 2]。那意味着第3次和第4次重试，都会等 2 秒。

道理是一样的，如果你想要精准控制每一次重试的节奏，数组才是正解。整数只是懒人用法。

retryAfter() 和 failed() 不能替代 $backoff

再看 retryAfter() 这个方法。它跟 $backoff 不是一套东西。retryAfter() 是针对单个任务实例的“下次重试前的最小等待时间”。它只在任务抛出异常并且没有被 failed() 方法捕获的情况下才生效。而 $backoff 是框架级的调度策略，优先级更高，也更稳定。

那什么时候用 retryAfter()呢？比如，你有个任务专门调第三方 API，对方有频率限制，你希望这个任务失败后至少等 10 秒再试。但你不想因为这一个任务就去改动全局的 $backoff 配置。这时候，retryAfter() 就派上用场了。不过得注意，这个方法的返回值必须是整数秒。如果返回 null，或者这个类根本没实现这个方法，那系统还是会回退到 $backoff 或者默认值。

至于 failed() 方法，千万别在里面写 sleep() 或者 usleep()，完全没用。因为当 failed() 执行时，当前的进程已经要退出了，worker 早就开始准备处理下一个任务了。所以 failed() 最好只用来做记录日志、发送告警、清理资源这类事情。想控制重试节奏？别指望它。

Redis 队列和数据库队列对 $backoff 的处理差异

队列驱动不同，$backoff 的表现也会不一样。如果你用的是 Redis 驱动（比如 redis 或 redis-cluster），它能精确地按照 $backoff 数组的值来做延迟重试。而 database 驱动呢？它依赖 a vailable_at 字段的写入时间，这就受数据库时区、worker 的启动频率影响，实际延迟可能会偏差个 1 秒甚至更多。

从性能角度看，database 驱动在高并发重试的场景下，很容易造成 jobs 表堆积。因为每次重试都要执行一次 update 加一次 select。而 Redis 用的是 zset 来排序，查找效率是 O(log N)，稳定得多。

所以，如果你的业务场景对重试节奏要求很严格，比如金融类的重试，建议换成 Redis 驱动。或者自己加一层自定义调度，比如用 dispatchAt() 手动控制。在 Redis 里，$backoff = [1, 2, 3] 会真实地写入到 zset 的 score 里，score 的值就是当前时间戳加上对应的秒数。worker 在 pop 任务时会按 score 排序，很准。

至于 database 驱动，$backoff 数组虽然在逻辑上有效，但最终写入到 a vailable_at 的值是由 PHP 的 time() + $delay 计算出来的。如果 worker 进程本身卡顿了一下，那就可能造成一批任务同时在同一个时间点重试，扎堆出现。

测试指数退避是否生效的最快方式

千万别等到生产环境出问题才去验证。在本地测试，有几个要点。

首先，别用 sync 驱动。因为它不走重试流程，测不出真实效果。你得用 redis 或者 database 驱动，然后配合 php artisan queue:work --once 这个命令，单次执行，配合日志来观察。

具体操作很简单：

• 在任务的 handle() 方法里，直接写一句 throw new RuntimeException('simulated fail');。
• 启动 worker：执行 php artisan queue:work redis --verbose --delay=0。注意 --delay=0 这个参数，它确保 worker 不会额外添加延迟。
• 然后盯着日志看。比如看到 [2024-05-20 10:11:22] local.INFO: Processing job...，再看下一条日志的时间。两次执行的时间差，是不是跟你配置的 $backoff 数组吻合？

还有一点，Lara vel 9.22 及之后的版本修复了一个 bug，就是 $backoff 在 Horizon 下会被忽略。如果你用的是旧版本，要么升级，要么手动去修一下 Illuminate\Queue\Jobs\RedisJob::release() 这个文件。

说句大实话，真正难调的地方不是配一个数组。而是不同驱动下的时钟同步、worker 进程的复用机制、以及任务失败后是否被其他中间件提前拦截。这些细节只要漏掉一个，你配置的 $backoff 就可能形同虚设。