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 订阅中断，广播就残了。
