websocket水平扩展需解决连接分散、状态隔离、消息不通问题，核心是状态外化与消息协同：用redis作协调中枢实现跨节点同步，负载均衡启用sticky session，按业务哈希分片降低广播压力，状态存redis并精确广播。

WebSocket 服务器要做水平扩展，核心是解决“连接分散、状态隔离、消息不通”这三大问题。单机部署时所有会话和广播都在内存里，一拆成多台机器，就容易出现用户收不到跨节点消息、重复推送、连接丢失等情况。真正可行的方案不是简单加机器，而是围绕状态外化和消息协同来设计。

用 Redis 实现跨节点会话与消息同步

这是目前最成熟、落地最多的方案。关键不是把 Redis 当缓存用，而是把它作为分布式协调中枢：

• 所有 WebSocket 服务实例连接同一个 Redis（或集群），共享频道订阅关系和在线用户映射表
• 客户端发消息 → 本机服务处理后，通过 Redis Pub/Sub 发布到公共频道（如 ws:chat:room123）
• 其他节点监听该频道，收到后只转发给本地已连接的对应房间用户，不全量广播
• 用户上线/下线事件也走 Redis 发布，各节点据此更新本地房间成员视图

负载均衡必须支持 sticky session

WebSocket 是长连接，不能像 HTTP 那样随意轮询分发。Nginx 或 HAProxy 必须启用会话保持策略：

WebSocket 8.18.2

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

下载

• 推荐用 ip_hash：同一客户端 IP 始终打到同一后端，适合公网 IP 较稳定的场景
• 更稳妥的是 cookie stickiness（如 Nginx 的 sticky cookie 模块）：首次建连时写入路由标识，后续请求携带该 cookie
• 避免使用纯轮询或最少连接，否则连接可能被重置，触发频繁重连

按业务维度做连接分片（Sharding）

单纯靠 Redis 广播，当用户量上到几十万，频道压力和本地转发开销仍会飙升。这时需要主动降低广播范围：

• 对房间 ID、用户 ID 或租户 ID 做哈希取模，比如 room_id % 8，划分成 8 个逻辑分片
• 每个 WebSocket 实例只负责处理自己分片内的连接和消息，跨分片消息走 Redis 转发，但仅限目标分片
• 用户进房间前，由网关或 API 层计算分片号并引导至对应后端地址（如 wss://ws-03.example.com）

状态外化 + 精确广播替代全量遍历

别再依赖“遍历所有连接”这种单机思维。集群中每个节点只维护局部状态：

• 用户会话元数据（如 user_id、room_id、token 过期时间）存 Redis Hash，带 TTL
• 房间成员列表用 Redis Set 管理，增删操作原子执行；广播前先查该 Set 获取当前在线成员
• 消息下发时，优先查本地内存连接池；若连接不在本地，则通过 Redis 查其归属节点，再发指令过去