Hyperf 的 hyperf/rocketmq 驱动不支持顺序消息,因其封装仅调用无 MessageQueueSelector 的 send() 方法,无法控制消息路由;需绕过驱动手写 DefaultMQProducer 并显式传 selector,Consumer 端须改用 MessageListenerOrderly 且 Topic 配置为 ORDER 类型。
Hyperf 默认的
驱动不原生支持顺序消息,直接调用
或配置
无法控制消息路由到指定队列——这是最常踩的坑,很多人卡在这一步就退回原生 SDK。
为什么
hyperf
/rocketmq 不能直接发顺序消息
该组件封装的是 RocketMQ 的普通消息发送逻辑,核心是
,而顺序消息必须使用带
参数的重载方法。驱动里没暴露这个入口,也没提供设置
或自定义队列选择器的能力。
的
内部调用的是无 selector 的 send 方法,消息会轮询投递到所有队列,天然破坏顺序
即使你在消息体里手动加
或
属性,Broker 不识别,Consumer 也不会按 Key 绑定队列
全局顺序(单队列 Topic)在该驱动中也无法强制,因为 Topic 创建、队列数配置、Producer 启动参数都不可控
绕过驱动,手写顺序 Producer 实例
最稳妥的做法是绕过
的封装,直接用官方
创建
,并显式传入
。注意保持与 Hyperf 生命周期一致(如随进程启动/销毁)。
Hyperf 3.1.66
本页面提供企业级 PHP 协程框架 Hyperf 3.1.66 版本的官方源码下载与完整更新日志。重点解析 v3.1.66 版本中新增的 gRPC 多客户端负载均衡支持、Pool 连接池全量刷新、Guzzle 持久化 Cookie 以及数据库 JSON 包含键查询等核心优化特性。
下载
在
中绑定自定义 Producer 类,例如
构造时传入
和
,调用
;
务必在回调中初始化,避免多 worker 复用同一实例
发送时用
形式,
通常是业务 ID(如
),
里做
路由
别忘了在
里调用
,否则进程退出时连接不释放
Consumer 端必须用 MessageListenerOrderly
Hyperf 的
注解默认走
,这会导致即使消息进了同一队列,也会被多个线程并发消费——顺序彻底失效。
必须弃用
,改用手动注册
,并调用
监听器内处理逻辑必须是同步、无锁、短耗时的;若需异步,得把消息内容复制后丢进协程或
,但原始消费线程仍要等回调返回
注意
方法返回
,否则会触发重复投递,破坏局部顺序语义
容易被忽略的部署细节
顺序消息不是写对代码就完事了。生产环境常因配置或集群状态导致短暂乱序,尤其在滚动发布或 Broker 重启时。
Topic 必须设为
类型(4.x 集群需在控制台勾选“顺序消息”;5.x 需用
设置
)
Consumer Group 的
必须为 1,否则一批拉多条会跨队列,无法保证单 Key 有序
如果用 ACL,
要传给 Producer 和 Consumer 实例,漏掉一个就会鉴权失败静默丢消息
hyperf/rocketmqproduce()ProducerDefaultMQProducer.send()MessageQueueSelectorShardingKeyhyperf/rocketmqProducer::send()KEYSshardingKeyhyperf/rocketmqrocketmq-clientDefaultMQProducerMessageQueueSelectorconfig/autoload/dependencies.phpOrderMessageProducer::classGroupNameNamesrvAddrstart()onWorkerStartsend(msg, selector, arg)argorder_idselectorarg.hashCode() % mqs.size()onWorkerStopshutdown()ConsumerMessageListenerConcurrently@ConsumerDefaultMQPushConsumerregisterMessageListener(new MessageListenerOrderly(...))ThreadPoolconsumeMessageConsumeOrderlyStatus.SUCCESSORDERmqadmin updateTopic-o trueConsumeMessageBatchMaxSizeAclClientRPCHook