WebSocket 从单节点到多节点：连接数上去之后，问题才真正开始

单节点的 WebSocket 服务很容易写：维护一个连接表，收到消息就推给对应的连接。但连接数上去、需要多节点部署之后，问题会从“怎么建连接”变成“消息怎么找到人”。

第一个问题，连接和节点的绑定。 一个用户连在节点 A，另一个用户连在节点 B，A 上的用户发消息给 B 上的用户，节点 A 不知道 B 的连接在哪里。解决方案是引入一个共享的连接注册表：每个节点在用户连接时把 user_id -> node_id 写入 Redis 或类似的共享存储，发消息时先查注册表，找到目标节点，再通过节点间通道转发。注册表要有过期机制，节点宕机时清理失效映射。

第二个问题，广播和房间。 群聊、直播间、协同编辑这类场景需要向一组连接广播。如果每个节点都维护一份房间成员表，节点间要同步成员变化；如果房间成员表放在共享存储里，每次广播都要查一次，延迟和成本都会上升。一个常见折中是：房间成员表分片存储在共享存储里，每个节点缓存自己负责的那部分，成员变化时通过发布订阅通知相关节点更新缓存。

第三个问题，节点扩缩容。 新节点加入时，部分用户需要重连到新节点；节点下线时，上面的连接要优雅迁移。做法是：新连接按一致性哈希或负载均衡策略分配到节点，旧连接不强制迁移，等自然断开后重连到新节点；节点下线前先停止接受新连接，通知客户端重连，等待连接排空后再关闭。这个过程需要客户端的重连逻辑配合，不能假设服务端能无缝迁移连接。

第四个问题，消息顺序和可靠性。 跨节点转发时，消息可能经过不同的网络路径，到达顺序不一定和发送顺序一致。如果业务要求顺序，需要在应用层加序列号，接收端做重排或丢弃过期消息。可靠性方面，WebSocket 本身不保证消息送达，重要消息要有确认和重试机制，或者降级到 HTTP 接口做补偿。

第五个问题，可观测性。 单节点时看连接数和消息量就够了，多节点时需要按节点、按房间、按用户维度看连接分布和消息延迟。一个常见故障是“某个节点连接数过高”，原因可能是负载均衡策略没有考虑节点容量，或者大量客户端在同一时间重连到同一个节点。监控要能发现这种不均衡，而不是等用户报障。

WebSocket 的多节点扩展，本质上是在解决“连接是有状态的，而节点是无状态的”这个矛盾。连接注册表、房间成员同步、节点扩缩容、消息顺序和可观测性，每一项都是在给这个矛盾打补丁。设计时先想清楚哪些状态必须共享、哪些可以本地缓存、哪些可以接受最终一致，比直接套一个“WebSocket 集群方案”更可靠。