Go集群架构设计：跨服WebSocket单发与群发中继-Golang-PHP中文网

gorilla/websocket本地广播在集群中必然失效，因各实例内存隔离，A节点无法访问B节点的hub.clients映射，导致仅本机连接能收到消息；须用Redis Pub/Sub跨实例中继，各节点订阅同一频道后向本地连接投递。

go集群架构设计：跨服websocket单发与群发中继

单机 gorilla/websocket 的 broadcast 机制天生无法跨实例，强行用本地 map[*Client]bool 群发，80% 的在线用户收不到消息——这不是 bug，是架构局限。

为什么 gorilla/websocket 本地广播在集群里必然失效

每个 Go 实例进程内存完全隔离：hub.clients 只存本机连接，A 实例里 user_id=u123 的 client，B 实例根本看不到。调用 hub.broadcast([]byte{...}) 后，只有当前实例的 goroutine 能遍历到自己的 map，其他机器静默丢弃。

常见错误现象包括：

前端无报错、无重连，但消息“发出去了却没人收到”
用 redis-cli pubsub channels 查不到订阅，或 PUBSUB NUMSUB ws:global:broadcast 返回 0
日志里反复出现 websocket: close sent 却没触发 onclose，说明连接早被另一实例接管或已断开

Redis Pub/Sub 是最轻量可行的跨实例中继方案

不用 Kafka、RabbitMQ，github.com/go-redis/redis/v8 + 原生 PUBLISH/SUBSCRIBE 就够用。延迟低（通常 PUBLISH 和 PSUBSCRIBE）、Go 客户端成熟。

关键设计点：

所有实例都 PSUBSCRIBE ws:global:broadcast 和 PSUBSCRIBE ws:user:* （用通配符支持单发）
消息体只传必要字段，例如：{"user_id":"u123","msg":"hi","type":"text"}，绝不要序列化 *Client 或 http.ResponseWriter
单发必须带 target_user_id，各实例收到后比对本地 client.UserID，命中才写入 client.Send channel
广播用固定 channel 名如 ws:global:broadcast，避免按房间或业务分 channel 导致订阅爆炸

单发必须解决“用户落在哪台实例”这个前提问题

没有这个信息，user_id 就只是个字符串，没法路由。常见做法有三种：

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

登录/握手阶段，由网关或服务发现组件把 user_id → pod_ip:port 映射写入 Redis，TTL 设为略长于心跳周期（比如 65s）
客户端首次连接时，服务端生成并返回一个 instance_id（如 svc-ws-01），前端存 localStorage，后续单发请求带上该 ID
用一致性哈希：对 user_id 做 sha256 取模，映射到预设的实例列表索引，要求实例数稳定、扩缩容需迁移部分 key

注意：如果用第一种方式，务必在 client.Close() 时主动 DEL 对应 key，否则会残留大量过期绑定。

本地 clients map 仍要保留，但职责已变

它不再承担“状态中心”角色，而是退化为纯本地缓存：只管本机连接的读写、心跳、异常关闭清理。所有跨实例逻辑必须绕过它，走 Redis 中继。

容易踩的坑：

在 Write 方法里直接调 c.Socket.WriteMessage，没做 select { case 判断，导致 panic 后 goroutine 泄漏
Redis 订阅 goroutine 没加 defer cancel()，实例重启时残留连接堆积
用 json.RawMessage 解包消息体却忘了检查 len(data) == 0，空 payload 触发 invalid character '}' 错误
没对 user_id 做白名单校验，恶意构造 target_user_id 可能打爆某实例内存