hyperf 3.1 异步队列高并发优化需三管齐下：1. 改用redis连接池并启用igbinary序列化；2. 合理限制消费者并发、添加内存监控与梯度重试；3. 拆分大任务为原子子任务且协程化消费。
Hyperf 3.1 异步队列在高并发批量任务场景下容易出现任务积压、消费者吞吐不足、Redis连接打满等问题，直接导致订单延迟处理、邮件发送卡顿、报表生成超时。这些问题不是靠堆机器能解决的，必须从队列驱动层、消费进程调度、任务结构三方面联动调优。
调整 Redis 驱动连接池与序列化策略
默认配置下，async-queue 使用单个 Redis 连接执行 BRPOP 和 LPUSH，在每秒千级任务推送时会成为瓶颈。
打开 config/autoload/async_queue.php，将 Redis 配置替换为连接池模式：
把 'driver' => ['type' => 'redis'] 改为：
'driver' => ['type' => 'redis', 'pool' => ['min_connections' => 5, 'max_connections' => 20]]
这一步必须做——【不改连接池，单连接撑不住批量入队压力，BRPOP 超时后任务直接丢失】。
同时启用 PHP 的 igbinary 序列化（若已安装）：在 driver 配置中追加 'serializer' => \Hyperf\AsyncQueue\Serializer\IgbinarySerializer::class。序列化体积比默认 serialize() 小 40% 以上，网络传输和 Redis 内存占用显著下降。
控制消费者并发与内存缓冲
盲目提高 concurrent.limit 反而会加剧 Redis 连接争抢和 PHP 内存溢出。真实压测表明：当单个消费者每秒处理超过 80 个中等复杂度任务（含 DB 查询+Redis 写入）时，内存常驻增长超 15MB/分钟。
第一步：在 async_queue.php 中设置 'concurrent' => ['limit' => 6]，先锁定一个安全基线值。
第二步：添加内存监控钩子——在 handle() 开头插入：if (memory_get_usage() > 128 * 1024 * 1024) { exit('OOM'); }，强制重启 worker 防止缓慢泄漏。
第三步：启用 retry_seconds 梯度退避，避免瞬时失败任务反复重试挤占通道：'retry_seconds' => [1, 3, 10, 30]。
拆分大任务为原子子任务
方法一：对含循环操作的任务类做「切片」处理
比如原 OrderBatchProcessJob 一次性处理 10000 条订单，改为接收 $offset 和 $limit 参数，每次只查 200 条 → 处理 → 提交 → 推送下一个分片任务。
方法二：用 Hyperf\AsyncQueue\Job::deliver() 主动投递子任务
在主任务 handle() 中，按业务逻辑边界（如按用户 ID Hash 分桶）生成多个轻量子任务实例，逐个调用 deliver() 入队。这样既规避单任务超时，又能让不同子任务被不同 worker 并行消费。
注意：子任务类必须可序列化，禁止传入 Closure、resource 或未声明的 private 属性——【传递不可序列化对象会导致任务静默丢弃，日志里只有一行 warning: serialize(): __sleep should return an array】。
启用协程化消费并关闭阻塞调用
Hyperf 3.1 默认 consumer 进程是同步阻塞模型。要真正释放协程红利，必须开启 task_enable_coroutine => true 并确保任务内所有 I/O 调用都是协程友好的。
修改 config/autoload/processes.php，找到 AsyncQueueProcess 配置项，在其 options 中加入：'task_enable_coroutine' => true。
然后检查所有 Job 类的 handle() 方法：
删掉 sleep(1)、curl_exec($ch)、PDO::query() 等阻塞调用；
替换成 Co::sleep(0.001)、Hyperf\HttpClient\HttpClient::post()、Db::select() 等协程 API。
这一步做完，同样硬件条件下消费者吞吐量可提升 3～5 倍。
