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