要在Hyperf 3.0中提升异步队列吞吐能力，必须通过多Consumer进程实现横向扩展：需安装async-queue组件、注册ConsumerProcess、按业务域拆分或数量扩容创建多个子类，并调优concurrent.limit与handle_timeout参数。
要在 Hyperf 3.0 中真正提升异步队列吞吐能力，必须突破单 Consumer 进程瓶颈，通过多进程消费实现横向扩展——这不同于旧版靠增加 worker_num，而是精准控制 ConsumerProcess 实例数量与协程并发粒度。
确认异步队列组件已安装并启用
执行 composer require hyperf/async-queue 安装组件；若 config/autoload/async_queue.php 不存在，运行 php bin/hyperf.php vendor:publish hyperf/async-queue 生成默认配置。
检查 config/autoload/processes.php 是否已注册 ConsumerProcess：Hyperf\AsyncQueue\Process\ConsumerProcess::class 必须存在，否则队列根本不会启动消费进程。
配置多个独立的 Consumer 进程实例
不要复用同一个 ConsumerProcess 类多次注册——Hyperf 会报错或静默忽略。正确做法是创建多个继承自 ConsumerProcess 的子类，每个类绑定独立配置项。
方法一：按业务域拆分（推荐）
在 app/Process/ 下新建文件 OrderConsumer.php：
namespace App\Process;<br>use Hyperf\AsyncQueue\Process\ConsumerProcess;<br>use Hyperf\Process\Annotation\Process;<br><br>#[Process(name: "order-consumer")]<br>class OrderConsumer extends ConsumerProcess<br>{<br> protected string $queue = 'order';<br> protected int $concurrent = 5;<br>}
再新建 NoticeConsumer.php，专用于通知类任务：protected string $queue = 'notice'; protected int $concurrent = 3;。这样不同业务队列互不干扰，避免订单积压拖垮短信发送。
方法二：纯数量扩容（适合同质化任务）
若所有任务逻辑一致且无优先级区分，可复制多个命名不同的 Consumer 类，如 Consumer1、Consumer2，并在 processes.php 中全部注册。但注意：【每个 Consumer 进程独占一个 Redis 连接池连接】，连接数会线性增长，需同步调大 Redis 连接池 max_connections 配置，否则出现 “Connection refused” 错误。
调整单个 Consumer 内部的协程并发上限
单个 Consumer 进程不是“单线程”，它默认使用协程池并发执行任务。关键参数在 async_queue.php 的 default 配置块中：
① 找到 'concurrent' => [ 'limit' => 10 ] 这一行，将 10 改为实际需要的数字。该值表示**单个 Consumer 进程内最多同时运行多少个协程来处理任务**。
② 若任务含大量 I/O（如调第三方 HTTP 接口），limit 设为 CPU 核数 × 2～3 较稳妥；若纯 CPU 计算（如加密解密），limit 超过 CPU 核数反而引发频繁上下文切换，建议设为 CPU 核数或略高。
③ 【务必同步检查 'handle_timeout' 值】：它定义单个任务协程最长允许执行时间（秒）。若设为 10，但某次数据库慢查询卡住 15 秒，该协程会被强制终止，任务进入失败队列——此时 retry_seconds 和 max_attempts 才会生效。线上建议设为预估最坏耗时 × 1.5。
验证多进程是否真实生效
启动服务后，执行 ps aux | grep "consumer"，应看到多个进程名含 order-consumer、notice-consumer 等关键词，而非仅一个 php bin/hyperf.php start。
进入 Redis CLI，执行 LLEN queue:order 和 LLEN queue:notice，确认两个队列长度变化趋势分离——例如下单高峰时 order 队列快速下降而 notice 队列平稳，证明分流成功。
访问 curl http://127.0.0.1:9501/status（需开启 server.status），查看返回 JSON 中的 task_worker_num 是总 Consumer 进程数，tasking_num 是当前正在执行任务的协程总数，二者相加应接近你配置的进程数 × concurrent.limit。
