解决WebSocket集群“失联”问题需用Redis实现全局会话管理：连接时注册userId↔serverId↔sessionId映射，支持多端登录与过期清理；通过Redis Pub/Sub转发消息，结合本地缓存与定时同步保障性能；网关层采用一致性哈希路由减少跨节点通信。
WebSocket 在单机环境下很好用，但一上生产集群就容易“失联”——用户连到 A 服务器，消息却发到了 B 服务器，本地 session 找不到，消息就丢了。解决这个问题，关键不是换技术栈，而是理清状态怎么管、消息怎么转。
用 Redis 做全局会话注册中心
每个 WebSocket 连接本质上是一个 userId ↔ sessionId ↔ serverId 的映射关系。单机时存在内存里就行，分布式下必须让所有节点都能查到这个关系。
- 连接建立时，把 userId + 当前 serverId + sessionId 写入 Redis，例如 key 是
ws:user:1001，value 是server-a:abc123 - 支持一个用户多端登录？那就用 Set 存多个值，而不是 String
- 记得设过期时间（比如 2 小时），配合心跳机制自动清理断连残留
靠 Redis Pub/Sub 转发跨节点消息
当业务服务要给用户 1001 推送消息，它不关心用户连在哪台机器——它只往 Redis 某个频道发一次，所有节点都订阅这个频道，各自判断“目标用户是不是在我这”。
- 推荐频道命名规则：
ws:msg:user:1001，精准投递；或ws:msg:group:tech，用于群组广播 - 每个服务节点启动时，订阅自己负责的频道（比如按 userId 取模分片，或全量订阅）
- 收到消息后，先查本地缓存有没有对应 sessionId；没有就去 Redis 查注册中心，再通过 RPC 或 HTTP 转发到目标节点（更重），或直接忽略（轻量）
本地缓存 + 定时清理，别全靠 Redis
高频读取 userId → sessionId 映射，全走 Redis 会成瓶颈。得在每台服务本地建一层 ConcurrentHashMap 缓存，但必须配好失效策略。
- 连接建立/关闭时，同步更新本地缓存和 Redis 注册中心
- 加个定时任务（比如每 30 秒扫描一次），比对本地缓存和 Redis 中的活跃连接列表，剔除已掉线的
- WebSocketSession 关闭时，主动从本地缓存和 Redis 中删除对应条目，避免“幽灵连接”
网关层做连接路由，减少后端复杂度
如果前端直连后端服务，Nginx 默认轮询会让同一用户反复跳节点，加剧 session 不一致问题。可以在接入层做点小优化。
- 启用 Nginx 的
ip_hash或基于 token 的 sticky session，让用户尽量固定在一台机器 - 更进一步：API 网关统一接管 WebSocket 升级请求，解析 token 获取 userId，再按一致性哈希路由到后端节点
- 这样大部分消息都在本节点完成，跨节点转发比例大幅下降，系统更稳也更省资源
