单节点websocket适合小规模场景，集群模式是高可用、高连接数的必然选择；核心在于明确连接归属（如redis hash记录user_node_map）、精准消息路由（查归属后定向投递），而非全量广播或本机瞎发。
单节点 WebSocket 服务器适合小规模、低并发场景，而集群模式是支撑高可用、高连接数实时系统的必然选择。关键不在“要不要集群”，而在“怎么让集群真正可靠地协同工作”——连接归属必须明确，消息路由必须精准，状态同步不能依赖运气。
单节点：简单但有硬边界
单机部署时，所有连接、会话、广播逻辑都在一个 JVM 内存中维护，比如用 ConcurrentHashMap<string websocketsession></string> 按用户 ID 或 token 存储连接。点对点推送、房间广播都可直接遍历内存完成，开发快、调试直观。
但它有三个不可绕过的瓶颈：
- 连接数受限于单机 CPU、内存和文件描述符上限（通常几千到几万）
- 无容错能力：进程崩溃即全量断连，无法自动恢复
- 无法水平扩容：加机器不等于加能力，负载只能堆在一台上
集群核心：连接归属 + 消息路由
集群不是把多个单节点简单并列，而是要解决“用户 A 连在节点 1，用户 B 连在节点 2，A 发消息给 B 怎么触达”这个根本问题。这需要两个基础设施：
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
-
会话注册中心：用 Redis Hash（如
HSET user_node_map u1001 ws-node-01）记录每个用户当前连接在哪台节点，支持快速查归属 -
跨节点通信通道：推荐 Redis Pub/Sub 做轻量控制面（如向
pubsub:node:ws-node-01发送定向消息），或用 Kafka/RocketMQ 做可靠投递（需 ACK 和重试）
每次发消息前，先查 Redis 知道目标在哪，再把消息推过去——不是广播给所有节点，更不是本机瞎发一通。
负载均衡与连接粘性
Nginx 是最常用的接入层，但要注意配置细节：
- 启用
Upgrade和Connection头转发，确保 WebSocket 协议升级成功 - 负载策略建议用轮询而非 IP Hash：WebSocket 连接建立后不会迁移，IP Hash 反而可能造成节点间连接不均
- 不要在 Nginx 层做连接超时主动关闭，应由后端心跳机制判断失效
消息分发的语义分级
不同业务场景对消息投递的要求差异极大，不能一套逻辑打天下：
- 私聊：严格一对一，必须查 user_node_map 定向投递，避免放大
- 房间群发：先判断房间内用户是否集中在同一节点——是，则本地广播；否则按用户逐个查归属、分别投递
- 系统广播（如公告）：可走 Pub/Sub 全局广播，但接收节点需自行过滤无效连接，防止空发
混淆 scope 会导致带宽浪费、CPU 暴涨，甚至消息重复。
