必须在任务分发侧和消费侧双端设防：分发端用ratelimiter限速、加随机延迟、禁用模型事件自动触发；消费端通过supervisor或horizon隔离队列并限制资源；任务内嵌熔断、健康检查及超时控制。
当大量订单创建、用户注册或第三方回调同时触发队列任务时，未加约束的消费会导致数据库连接打满、Redis阻塞、第三方API被限频甚至服务雪崩。必须在任务分发侧和消费侧双端设防，而非依赖单一配置。
分发端：按业务维度控制任务生成速率
任务不是越多越好，高频触发源必须主动节流，否则Worker再快也来不及处理。
第一步：在控制器或服务类中，用 Laravel 内置 RateLimiter 限制每秒可生成的任务数。例如对支付回调入口，限制每秒最多生成3个支付确认任务：
RateLimiter::attempt('payment_dispatch:'.$request->ip(), 3, function () use ($order) {
ProcessPaymentJob::dispatch($order->id)->onQueue('urgent');
return true;
});
注意：key 中拼接 $request->ip() 是为了防单IP刷量，但若走 Nginx 反向代理，需先在 Kernel.php 中配置 TRUSTED_PROXIES，否则所有请求都算作 127.0.0.1，限流失效。
第二步：对非实时性任务（如日志归档、统计汇总），强制添加随机延迟，打散执行时间点。直接在 dispatch() 后链式调用 → delay(rand(1, 30))，避免整点时刻任务扎堆。
第三步：禁用模型事件自动触发队列任务。Eloquent 的 creating/created 等事件若绑定了 dispatch，会在事务内立即序列化对象——此时数据可能未落库，且无法感知当前是否处于队列上下文。改用显式调用，或在事件处理器中判断 !app()->runningInConsole() && !app()->runningUnitTests()。
消费端：为不同队列设置独立资源配额
不能让一个 slow_query 任务卡住整个 urgent 队列。必须按队列隔离 Worker 进程，并硬性限制其资源消耗。
方法一：用 Supervisor 分别管理 urgent 和 default 队列的 Worker
为 urgent 队列单独配置 supervisor.conf 片段，关键参数如下：
command=php /var/www/artisan queue:work --queue=urgent --max-jobs=20 --timeout=60 --memory=128
其中 【--max-jobs=20】 表示该进程最多处理 20 个任务后自动退出重启，防止内存泄漏累积；【--timeout=60】 强制超时终止，避免某个任务死循环拖垮全部 urgent 消费能力。
方法二：用 Horizon 动态调整队列权重与并发数
在 config/horizon.php 中，将 urgent 队列的 balance 配置为 'simple'，并显式指定 processes：
'environments' => [
'production' => [
'supervisor-1' => [
'connection' => 'redis',
'queue' => ['urgent'],
'processes' => 4,
'balance' => 'simple',
],
],
]
Horizon 启动后，urgent 队列固定由 4 个进程消费，default 队列另配 2 个进程，彻底避免资源争抢。
任务内部：嵌入轻量级运行时熔断
即使前两层都守住了，单个任务仍可能因外部依赖异常而无限重试或超时。必须在 handle() 内部植入快速失败逻辑。
在任务类的 handle() 方法开头插入：
if (Cache::get('stop_processing_urgent', false)) {
Log::warning('Urgent queue manually paused via cache key');
return;
}
这行代码允许运维通过 redis-cli set stop_processing_urgent 1 临时关停 urgent 队列消费，无需重启 Worker 进程。
接着检查当前 Redis 连接健康度：
try {
Redis::ping();
} catch (\Exception $e) {
Log::error('Redis unreachable in urgent job, aborting');
throw new \Exception('Critical dependency down'); // 触发重试或进 failed_jobs
}
最后一步：对调用第三方 API 的任务，强制设置 Guzzle HTTP 客户端 timeout ≤ 15 秒，并禁用 retry —— 让失败尽快暴露，而不是在重试队列里反复排队消耗资源。
