靠谱估算是用加权中位数：仅统计同一job_class+关键参数组合的最近15次成功耗时，排除失败/重试干扰；通过jobprocessed/jobfailed事件埋点，redis存储并自动截取；无历史数据时返回配置化兜底值；前端返回预估剩余时间而非百分比。
队列任务执行时间怎么估算才靠谱
直接用平均耗时预测进度会严重失真——新任务可能比历史快 3 倍，也可能卡在某个慢 SQL 上拖成 10 分钟。Laravel 自身不提供进度估算，得自己补一层轻量逻辑。
核心思路是：只记录「完成态」的执行时间，排除失败、重试、超时任务的干扰；对同一 job_class + 关键参数组合（比如 $batchId 或 $chunkSize）维护最近 N 次成功耗时，用加权中位数（非平均值）抗异常点。
- 失败/重试的任务不计入统计，否则会把 5s 的正常任务拉高到 40s（因重试了 7 次）
- 按
job_class+ 可识别业务维度分桶，比如App\Jobs\ExportUserReportJob和$format === 'xlsx'单独建桶 - 推荐保留最近 15 条成功记录，用
array_values(array_slice($times, -15))动态截取，避免数据膨胀
Laravel 队列监听器里怎么安全采集耗时
别在 handle() 开头记开始时间、结尾算差值——如果 job 被 kill 或超时退出，时间戳就永远悬着。正确做法是利用 Laravel 的 JobProcessed 和 JobFailed 事件，在外部统一埋点。
在 App\Providers\EventServiceProvider 中注册：
protected $listen = [
'Illuminate\Queue\Events\JobProcessed' => [
'App\Listeners\LogJobDuration',
],
'Illuminate\Queue\Events\JobFailed' => [
'App\Listeners\DiscardFailedJobDuration',
],
];
-
JobProcessed事件里能拿到$event->job->resolveName()、$event->job->payload()['data']['command']（含反序列化后的参数），可提取关键标识字段 - 用 Redis 的
LPUSH job_duration:{class}:{key} {ms}存耗时，配合LTRIM job_duration:{class}:{key} 0 14控制长度 - 别用数据库存——高并发下写入延迟和锁竞争会让统计本身变瓶颈
预测时怎么避免「刚上线就瞎猜」
新 job 类型或参数组合第一次运行时，Redis 里没历史数据，直接返回 null 或抛异常都不行。必须有兜底策略。
- 查不到历史数据时，返回预设的保守基准值，比如
3000（3 秒），而不是0或inf - 允许通过配置项
config('queue.job_duration_fallback_ms')统一管理默认值，方便灰度调整 - 对低频 job（比如每月跑一次的报表），可 fallback 到同类 job 的平均值，用
str_replace('Monthly', 'Weekly', $class)粗粒度匹配，比纯拍脑袋强
前端轮询进度时后端该返回什么
别传「已执行 62%」这种幻觉数字。用户真正需要的是「大概还要等多久」，以及「现在卡在哪」。
API 返回结构建议长这样：
{
"estimated_remaining_ms": 8400,
"current_stage": "exporting",
"history_count": 12,
"is_stuck": false
}
-
estimated_remaining_ms=total_items × median_duration_per_item − elapsed_ms，比百分比更防误导 -
current_stage必须由 job 主动上报（比如在循环里每处理 100 条发一次Cache::set("job_{$id}_stage", "exporting")），不能靠猜 -
is_stuck判断逻辑：当前耗时 >3 × median_duration且current_stage超过 90 秒未更新 → 触发告警，不是前端能解决的
真正的难点不在算法，而在于 stage 上报时机和失败清理——job 进程崩了，缓存里的 stage 就永远滞留。所以每次上报前先用 Cache::add("job_{$id}_lock", true, 30) 做轻量互斥，崩了也会自动过期。
