hyperf高频队列本质是基于redis的轻量异步队列，通过concurrent.limit等参数调优及@asyncqueue注解或queue::push投递任务，配合监控与失败处理保障高并发稳定吞吐。
Hyperf 的高频队列功能，本质是通过异步队列组件（hyperf/async-queue）在高并发场景下分流耗时任务，避免阻塞主请求流程。它不依赖外部中间件（如 RabbitMQ/Kafka），默认基于 Redis 实现，轻量、启动快、协程友好，特别适合订单处理、通知推送、报表生成等短中频次但需稳定吞吐的业务。
基础配置与启动要点
高频使用前必须确认三项配置已就位：
-
安装组件：运行
composer require hyperf/async-queue -
发布配置：执行
php bin/hyperf.php vendor:publish hyperf/async-queue，生成config/autoload/async_queue.php -
注册消费者进程：在
config/autoload/processes.php中添加Hyperf\AsyncQueue\Process\ConsumerProcess::class，否则任务不会被消费
注意：processes 参数在配置中应设为 0 或省略（新版推荐设为 0），实际并发数由 concurrent.limit 控制，避免进程数误配导致资源争抢。
高频任务投递的两种常用方式
根据业务耦合度选择更合适的方式：
-
显式调用 Queue::push()：适合需要动态构造参数、多条件分支或跨模块复用的场景。例如在控制器中注入
Hyperf\AsyncQueue\Queue，然后$queue->push(new OrderProcessJob($orderId)) -
@AsyncQueue 注解：适合方法逻辑固定、参数明确的高频小任务。在 Service 方法上加注解
#[AsyncQueue]，调用该方法即自动入队，无需手动 new Job，代码更简洁
注解方式要求方法返回值为 void，且参数必须可序列化；若需传递对象，建议只传 ID，再在 Job 内部查库，避免序列化失败或数据过期。
应对高频的核心调优参数
默认配置适合低流量，高频场景需针对性调整：
-
concurrent.limit：控制单个消费者进程同时处理的任务数。建议设为 CPU 核心数 × 2～4，例如 4 核机器可设为 8～12，避免 I/O 等待拖慢整体吞吐 -
handle_timeout：单个任务最长处理时间。高频任务应尽量 ≤5 秒，超时会触发重试或进入失败队列，防止“慢任务”拖垮整个队列 -
retry_seconds：支持数组形式，如[1, 3, 6, 12]，实现退避重试，降低瞬时重试压力；高频写操作（如日志记录）可设为[0.1, 0.3, 0.5]加速恢复 -
channel：可按业务隔离，如'order_queue'、'notify_queue'，避免不同优先级任务相互干扰
监控与失败任务处理
高频运行下失败任务积累快，需主动干预：
- 查看当前队列长度：
redis-cli -p 6379 llen "queue:default"（channel 为 default 时） - 清理失败任务：
php bin/hyperf.php async-queue:flush-failed - 重试指定失败任务：
php bin/hyperf.php async-queue:retry {id} - 启用日志记录：在
config/autoload/logger.php中确保async-queue日志通道开启，便于排查超时或异常中断
建议在定时任务中加入失败队列扫描，对连续失败 ≥3 次的任务人工介入，防止雪崩。
