Hyperf通过Redis Pub/Sub实现跨进程WebSocket广播:所有Worker启动时用go()协程订阅统一频道(如ws:global:msg),收到消息后解析并调用Sender->push()向本进程连接推送;客户端消息统一由Redis::publish发布,确保全集群Worker一致消费,避免进程隔离导致的广播盲区。

Hyperf WebSocket 连接分散在多个 Worker 进程,怎么让消息跨进程广播?
单机多 Worker 模式下,Hyperf\WebSocketServer\Sender 只能向本进程内的连接发消息,其他 Worker 里的客户端收不到——这不是 bug,是设计使然。想全局广播,必须绕过进程隔离,走外部中间件。
Redis Pub/Sub 是最轻量、最契合的方案:不依赖持久化,低延迟,天然支持一对多分发,且 Hyperf 官方 hyperf/redis 已内置封装。
- 别用 Redis List + BLPOP 模拟队列:会丢消息、难扩展、无法实时广播
- 别自己写进程间通信(如 Unix Socket):维护成本高,且集群扩缩容时失效
- 订阅频道建议固定前缀,比如
ws:global:msg,避免不同环境或服务冲突
如何用 Redis Pub/Sub 在 Hyperf 中实现跨进程消息中转?
核心思路是:所有 Worker 进程启动时,都用 Redis::subscribe() 监听同一个频道;收到消息后,解析并调用 $sender->push() 推给本进程内所有匹配连接。
注意:订阅必须在协程环境下运行,且不能阻塞主事件循环——得用 go() 启动独立协程,同时监听多个频道时用数组传参。
- 订阅逻辑应放在
Command或Listener中,在ServerStart事件后执行,确保 Redis 连接已就绪 - 频道名不要硬编码,从
config/autoload/redis.php或环境变量读取,方便多环境切换 - 消息体建议统一为 JSON 字符串,含
type、data、target字段,便于后续做定向推送(如只推给某用户 ID)
go(function () {
$redis = \Hyperf\Redis\Redis::instance();
$redis->subscribe(['ws:global:msg'], function ($redis, $channel, $message) {
$payload = json_decode($message, true);
if (!$payload || !isset($payload['data'])) {
return;
}
// 获取当前进程的 Sender 实例
$sender = \Hyperf\WebSocketServer\Sender::getInstance();
// 广播给本进程所有在线连接(可按 payload['target'] 过滤)
foreach ($sender->getFdList() as $fd) {
$sender->push($fd, json_encode($payload['data']));
}
});
});
客户端发消息 → 触发 Redis 发布 → 全集群接收,怎么串联?
客户端通过 WebSocket 发来的消息,不应由当前 Worker 直接处理广播,而应统一发布到 Redis 频道,让所有 Worker(包括自己)一视同仁地消费——这样逻辑一致、无盲区、易调试。
典型场景:用户 A 发送聊天消息,需实时推送给房间内所有用户(无论他们连在哪个 Worker 上)。
- 在
WebSocketController的onMessage方法里,不做$sender->broadcast(),而是调用Redis::publish('ws:global:msg', json_encode([...])) - 如果需要「仅广播给某房间」,可在频道名中嵌入房间 ID,例如
ws:room:1001,各 Worker 订阅对应频道即可,避免全量消费后过滤 - 注意
publish是同步操作,但极快;若并发极高,可考虑加一层协程池限流,不过通常没必要
为什么不用 Hyperf 自带的 Hyperf\RpcClient\Contract\TcpServiceInterface 或 Swoole Table?
有人试过用 Swoole Table 做 FD 映射表,再遍历所有 Worker 的 Table 来发消息——理论上可行,但实际踩坑多:
- Swoole Table 不支持跨进程广播,仍需额外通信机制同步状态
- RPC 调用链路长、序列化开销大、超时和重试逻辑复杂,对纯广播场景属于过度设计
- Redis Pub/Sub 故障时容易感知(
publish报错或订阅协程退出),而自研通信一旦出问题,往往静默丢消息
真正要注意的是 Redis 连接稳定性:务必配置 retry_times 和 connect_timeout,并在 subscribe 协程里加异常捕获与自动重连逻辑——这点很容易被忽略,线上跑几天后可能因网络抖动导致部分 Worker 订阅中断,广播就残了。











