Laravel Redis队列性能瓶颈不在Redis本身，而在配置：block_for需按任务密度选5秒或null；retry_after须比P95耗时多10秒；Horizon需设前缀、禁用冗余采集、固定进程数；phpredis须复用连接。
直接上结论：Laravel用Redis做队列驱动本身不慢，但默认配置下吞吐常被retry_after、block_for、Horizon采集逻辑和共享Redis连接拖垮。真正卡点不在Redis，而在Laravel怎么用它。
redis驱动配置里block_for设null还是设5？
设null会让queue:work持续阻塞等待新任务，CPU空转高、响应延迟低；设5（秒）则每5秒轮询一次，降低Redis压力但可能增加平均延迟。实际选哪个，取决于你的任务密度：
- 秒杀/审核类高频短任务（每秒几十个入队）→ 用
block_for => 5，避免Worker进程长期占着连接不放 - 低频长任务（如导出、邮件）→
block_for => null更省资源，也减少无效轮询 - 注意：
block_for只对Redis列表BLPOP生效，若你用了redis.client = phpredis且启用了连接池，设太小反而触发频繁重连
为什么retry_after必须比任务最长执行时间多至少10秒？
这个值不是“超时就重试”，而是“Redis多久后把未ACK的任务放回队列”。如果设得太紧，比如任务实际要8秒完成，你却设retry_after => 10，那第9秒时Redis就认为它失败了，把它塞回队列——结果同一任务被重复执行两次。
- 查真实耗时：在Job的
handle()开头记microtime(true)，结尾再算差值，取P95值+10秒作为安全值 - 别信文档写的“90秒默认值”——电商下单任务通常3–6秒，设成30足够；内容审核类可能20秒，设成45更稳
- 设太大（如180）会导致失败任务卡在“processing”状态太久，监控难发现
Horizon启动后Redis CPU飙升，停掉就正常？
这是典型Horizon指标采集反噬。它默认每秒跑ZRANGE、HGETALL、LLEN，还可能触发KEYS *全库扫描——尤其没配HORIZON_PREFIX时。
- 立刻在
.env加：HORIZON_PREFIX=horizon:（末尾冒号不能少） - 关掉最重两项采集：
'metrics' => ['jobs' => true, 'requests' => false, 'redis' => false] -
'trim' => ['recent' => 50, 'failed' => 200]，别用默认1000——UI只展示这么多，但底层key照存不误，内存越积越多 - 真要清数据，运行
php artisan horizon:clear，不是horizon:terminate
高优队列（如high）总被default拖慢？
Horizon的auto均衡模式根本不适合突发流量。它等“观察到积压”才调进程数，等它反应过来，high队列已堆满。
- 在
config/horizon.php的environments里写死：'high' => ['processes' => 6]、'default' => ['processes' => 2] - 禁用自动平衡：
'balance' => false，否则Horizon会覆盖你的配置 - 给
high队列配独立Redis连接（如redis-high），避免和default抢同一个连接池 - 验证是否生效：
redis-cli llen queues:high看pending数，再ps aux | grep horizon确认子进程数匹配
最容易被忽略的其实是REDIS_CLIENT选型和连接复用。用predis时连接是单例复用的，但phpredis默认每次新建连接——高并发下Redis连接数暴涨，直接触发maxclients限制。这点不调，其他都白搭。
