Laravel任务批处理设置方法

Laravel 的 Job Batching 机制本身不支持单个批次内按优先级调度任务，所有子任务强制共享同一队列和元数据，导致即使为不同 Job 显式指定 `onQueue()` 也会被忽略——高优任务极易被低优任务阻塞，违背 SLA 要求；真正可行的方案是将任务按业务优先级（如 P0/P1）拆分为多个独立 Batch，分别绑定 `high`/`default`/`low` 等专用队列，并配合隔离运行的 worker 进程实现资源与执行时序的硬性隔离；同时，为保障关键后续操作（如成功通知）秒级响应，需将 `then()` 回调进一步投递至独立的 `urgent` 队列并配置专属 Redis database 和高频轮询 worker；更不可忽视的是，默认批处理元数据存储不保留优先级字段，必须自定义 `DatabaseBatchRepository` 注入 `priority_level`，否则监控、重试与审计将彻底失去优先级上下文——这套「多批次+多队列+多worker+自定义元数据」组合拳，才是 Laravel 中落地任务优先级控制的唯一稳健路径。

直接说结论：Laravel 的 Job Batching 本身不支持单个 Batch 内部按优先级调度，必须靠「多批次 + 多队列 + 独立 worker」组合实现优先级控制；想在同一个 Bus::batch() 里给某些 Job 加急，行不通。

为什么不能在同一个 Batch 里混用优先级

Batch 是原子性元数据容器，所有子任务共享同一张 job_batches 记录、同一超时设置、同一完成回调触发逻辑。框架底层把整个 Batch 当作一个“超级 Job”来 dispatch，所有子任务都走 onQueue() 指定的**同一个队列名**——即使你在每个 Job 实例上调用 onQueue('high')，也会被 Batch 构建过程忽略。

• 常见错误现象：Bus::batch([new SendNotificationJob()->onQueue('high'), new ProcessReportJob()->onQueue('low')])->dispatch()，结果两个任务全进了 default 队列
• 根本原因：Bus::batch() 只认顶层 onQueue() 调用，子 Job 的队列设置会被丢弃
• 性能影响：强行塞进同一队列会导致高优任务被低优任务阻塞，违背 SLA 设计初衷

正确做法：按优先级拆成多个独立 Batch

把原始任务集合按业务等级切分，每个等级单独创建 Batch，并绑定对应队列。这是目前最稳定、最易监控的方案。

• 确保 config/queue.php 中已声明 'high'、'default'、'low' 等队列连接，且驱动为 database 或 redis
• 分级示例：$p0Jobs = collect($allJobs)->filter(fn($j) => $j->priority === 'P0');
• 分别 dispatch：Bus::batch($p0Jobs)->onQueue('high')->then(...)->dispatch(); 和 Bus::batch($p1Jobs)->onQueue('default')->then(...)->dispatch();
• 启动隔离 worker：php artisan queue:work --queue=high 和 php artisan queue:work --queue=default 必须分开运行，不能共用一个进程

如何让关键后续操作立刻执行（比如发成功通知）

Batch 的 then() 回调本身是个普通 Job，也会排队。若需“秒级响应”，必须把它再 dispatch 到一个专用紧急队列。

• 在 then() 闭包里不要直接写业务逻辑，而是 dispatch 新任务：dispatch(new SendBatchSuccessAlert())->onQueue('urgent');
• 'urgent' 队列建议用独立 Redis database（如 database => 15），避免和主队列争抢连接
• 为 urgent 队列配专属 worker：php artisan queue:work --queue=urgent --sleep=1 --max-jobs=1000
• 验证是否生效：在 SendBatchSuccessAlert::handle() 开头加 Log::info('Urgent fired at ' . now());，对比主 Batch 完成时间戳

容易被忽略的坑：Batch 元数据存储与重试上下文

默认 DatabaseBatchRepository 不存优先级字段，导致你无法从 job_batches 表里查出某个 Batch 属于哪一级——这对人工重试、监控告警、审计追踪都是硬伤。

必须自定义 Repository：继承 Illuminate\Bus\DatabaseBatchRepository，覆盖 store() 方法，在插入前向 $batch 数组注入 'priority_level' => 'P0' 字段。否则，当某个 Batch 卡住或失败，你只能靠日志反推，没法在后台页面直接筛选“所有 P0 级未完成 Batch”。

以上就是《Laravel任务批处理设置方法》的详细内容，更多关于Laravel的资料请关注golang学习网公众号！