跨服WebSocket单发与群发需依赖Redis Pub/Sub实现消息中继，因gorilla/websocket仅支持本地连接操作，各节点须独立维护clients map并订阅统一频道，通过user_id定位目标实例后定向推送或按房间分组广播。
跨服 websocket 的单发和群发在 go 集群中不是“加个 redis 就能自动转发”的事——它本质是状态分片 + 消息路由问题，不处理好连接归属、会话定位、广播范围，就会出现消息丢失、重复投递或只发到本机连接的典型故障。
为什么 gorilla/websocket 本身不支持跨服单发
gorilla/websocket 的 conn.WriteMessage() 只作用于当前 goroutine 绑定的本地连接实例。集群中每个节点只持有自己 Accept 到的连接，conn 对象不跨进程、不跨网络，也没有内置的远程寻址能力。你调用一次 WriteMessage()，它只会写进本机 TCP socket 缓冲区，对其他节点上的用户完全不可见。
- 常见错误现象：A 用户发消息给 B，B 在另一台机器上，结果 B 收不到；或者只在 A 所连节点的日志里看到“已发送”，但实际没触达
- 关键原因：没有统一的会话注册中心，服务端不知道“用户 B 当前在哪台节点上”
- 性能影响：若强行用全量广播（比如所有节点都向自己持有的全部连接发一遍），消息放大 N 倍，带宽和 CPU 都浪费在无效投递上
用 Redis Pub/Sub 实现跨服单发的最小可行路径
单发的核心是“定向寻址”：先查目标用户所在节点，再把消息推过去。Redis 的 Pub/Sub 不适合做可靠投递，但足够轻量做控制面通信——只要配合一个稳定的会话注册表（比如 Redis Hash 或 Sorted Set）。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 每台 WebSocket 节点启动时，往 Redis 写入自己的服务标识（如
"node:ws-01"）和心跳时间戳 - 用户上线时，节点将
user_id → node_id映射存入 Redis Hash，例如：HSET user_node_map "u123" "ws-01" - 发送单聊消息时，先
HGET user_node_map "u123"查到目标节点，再向对应频道（如pubsub:node:ws-01）publish 消息体 - 各节点订阅自己的频道（
SUBSCRIBE pubsub:node:ws-01），收到后从本地map[*Client]bool中取出对应client并调用WriteMessage() - 注意：Redis Pub/Sub 是 fire-and-forget，不保证送达。若业务要求强一致性，需改用 Redis Stream + consumer group + ACK 机制
群发（房间/频道广播）必须区分 scope：本地 vs 全局
群发不是“所有节点一起吼”，而是按语义拆解：有些群是逻辑隔离的（如游戏中的副本），有些是全局可见的（如系统公告）。混淆这两者会导致严重资源错配。
-
本地群发：用户都在同一节点（如小聊天室、协作文档 session），直接遍历本地
hub.clientsmap 即可，零跨网开销 -
全局群发：需先确认房间成员分布（查 Redis Set：
SMEMBERS room:general），再按user_id → node_id分组，对每个目标节点单独 publish —— 这才是真正的“广播”，不是 flood - 容易踩的坑：
publish时没带房间 ID 上下文，导致接收方无法判断该消息属于哪个逻辑群组；或把房间成员列表缓存在本地内存，集群扩缩容后数据不一致 - 参数差异提醒：Redis
PUBLISH命令本身不支持 payload 大小限制，但实际中建议控制在 100KB 内；超大消息应转为存储 URL + 推送通知
真正难的从来不是“怎么发”，而是“发之前怎么确认对方在线、在哪、属于哪个上下文”。Redis 只解决路由，不解决状态一致性；连接断连未及时清理、节点宕机未触发 rehash、用户重连时房间归属未同步——这些细节漏掉一个，群发就变成随机发。
