如何在Golang中实现WebSocket集群消息广播 Go语言Redis PubSub结合

单机广播撑不住必须上redis pub/sub，因gorilla/websocket的broadcast channel仅限本进程，多节点部署时消息无法跨实例传递；redis pub/sub提供轻量、低延迟、无状态的跨进程中继，满足websocket“即发即达”需求。

为什么单机广播撑不住，必须上 Redis Pub/Sub

单机 gorilla/websocket 的 broadcast channel 只能触达本进程内的连接。一旦服务横向扩成多节点（比如用 nginx 做负载均衡），A 节点上的用户发的消息，B 节点上的用户根本收不到——这不是代码写得不够好，是架构层面的天然隔离。

Redis Pub/Sub 是最轻量、最直接的跨进程消息中继方案：它不持久化、低延迟、无状态，正好匹配 WebSocket 广播“即发即达、不重不漏”的语义。别被“消息队列”这个词吓住，这里你不需要 kafka 或 rabbitmq 的复杂运维。

• 生产环境并发超 500 连接且部署 ≥2 实例时，Redis Pub/Sub 就不是可选项，而是必选项
• 本地开发调试可以先用单机模式，但 go run 启多个端口模拟集群时，立刻会暴露消息丢失问题
• 注意：Redis 的 Pub/Sub 是“发后即焚”，没有消费确认机制。如果某节点临时宕机，它错过的广播消息不会补推——这对聊天室类场景可接受；若需可靠投递（如订单通知），得换 Redis Stream + ACK

如何用 gorilla/websocket + Redis 实现跨节点广播

核心思路是把原来单机的 broadcast channel 替换成 Redis 的发布/订阅通道：所有节点都 SUBSCRIBE 同一个频道（如 ws:global:broadcast），任意节点收到客户端消息后，不再往本地 channel 写，而是 PUBLISH 到该频道。

关键实操点：

立即学习“go语言免费学习笔记（深入）”；

• 每个服务实例启动时，用 redis.NewClient() 连 Redis，并起一个独立 goroutine 调用 pubsub := client.Subscribe(ctx, "ws:global:broadcast")，然后循环 pubsub.ReceiveMessage(ctx) —— 收到消息就遍历本机 clients map 广播
• 客户端消息入口（readPump）里，去掉 broadcast ，换成 <code>client.Publish(ctx, "ws:global:broadcast", msg)
• 务必为 Redis 操作加 context 超时：ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)，避免网络抖动卡死 goroutine
• 不要在 Subscribe 的 goroutine 里直接调用 conn.WriteMessage() —— 需通过每个连接自己的 writePump channel 中转，否则可能并发写 panic

连接管理仍必须本地维护，Redis 不替代 map[*websocket.Conn]bool

Redis 解决的是“消息怎么传出去”，不是“连谁、怎么发”。每个节点依然要独立维护本机的 clients map，用 sync.RWMutex 保护增删操作。这是最容易混淆的点：有人以为“上了 Redis 就不用管本地连接了”，结果出现向已断开连接重复写、panic 报 use of closed network connection。

• defer conn.Close() 后必须同步执行 mutex.Lock(); delete(clients, conn); mutex.Unlock()，不能只靠心跳检测延后清理
• 心跳（ping/pong）逻辑仍在本机做：服务端每 30 秒 conn.WriteMessage(websocket.PingMessage, nil)，读协程设 conn.SetReadDeadline()，超时就删连接
• Redis Pub/Sub 不感知连接生命周期，它只管转发字节流。上线/下线事件若需广播（如“xxx 加入群聊”），仍要走同一套 Pub/Sub 流程，前端靠 type 字段区分

常见错误现象与定位方法

集群广播出问题，90% 出现在三类地方：Redis 连接泄漏、本地连接未及时清理、Pub/Sub 订阅未持久化。遇到收不到消息，按这个顺序查：

• 检查 Redis CLI：redis-cli PUBSUB NUMSUB ws:global:broadcast，返回数应等于你的服务实例数。若为 0，说明某个实例的 Subscribe goroutine 已 panic 退出（常见于未 recover context.Canceled）
• 抓包或打日志看 readPump 是否真调用了 Publish：加一行 log.Printf("publishing %d bytes to redis", len(msg))，确认消息发出
• 在 writePump 里对每个 conn.WriteMessage() 包一层 recover()，捕获 websocket.ErrCloseSent 或 io.EOF 后立即从 clients 删除，否则残留连接会持续占用内存
• 用 redis-cli MONITOR 实时观察是否有 PUBLISH 命令发出，以及各实例是否在 SUBSCRIBE —— 这是最直接的链路验证

真正麻烦的不是写通，而是写稳：Pub/Sub 的“无状态”特性意味着你得在每个节点上把连接生命周期、错误恢复、资源释放全兜住。Redis 只负责传话，谁来听、听完了干啥，还得自己定规矩。