websocket分布式房间管理需依赖外部协调机制，核心是用redis pub/sub广播消息、redis hash/set统一维护房间成员状态，并可选消息队列提升可靠性及负载均衡优化路由。
WebSocket 本身是点对点的长连接，不自带房间、广播或集群能力。要实现分布式房间管理（比如多个 Node.js 实例部署在不同服务器上），关键不是靠 WebSocket 协议本身，而是靠外部协调机制——把“谁在哪个房间”“消息该发给谁”这些状态从单机内存移到共享存储或消息中间件中。
用 Redis Pub/Sub 做跨实例消息广播
每个 WebSocket 服务实例都订阅同一个 Redis 频道（如 room:lobby），当用户在 A 实例加入房间并发送消息时，A 实例不直接推给其他客户端，而是 publish 到 Redis；B、C 等实例监听到后，再把消息转发给各自连接的、属于该房间的客户端。
- 优点：低延迟、解耦、天然支持多实例
- 注意：Redis 不负责维护“用户-房间”映射关系，这部分仍需自己设计（比如用 Redis Hash 存 room:lobby → [uid1, uid2]）
- 示例：用户 uid100 在实例 A 发送消息到 lobby，A 写入 Redis Hash 并 publish 消息；实例 B 读取 Hash 知道 uid200 也在 lobby，就把消息推给 uid200 的连接
用 Redis 作为房间成员状态中心
放弃本地 Map 存房间成员，统一用 Redis 数据结构维护：
- Hash：key 是 room:{roomId}，field 是用户 ID，value 可存客户端信息（如 IP、加入时间）
- Set：key 是 room:{roomId}:members，只存活跃用户 ID，适合快速获取成员列表
- 每次 join/leave 都通过 Redis 原子操作（HSET / HDEL / SADD / SREM）更新，避免多实例间状态不一致
- 配合 TTL 设置自动清理离线用户（比如用户断连后 30 秒未心跳，用后台任务或 Redis 过期事件清理）
用消息队列（如 RabbitMQ/Kafka）替代 Redis Pub/Sub（适合高可靠场景）
当需要消息持久化、重试、顺序保证或审计日志时，可将房间消息走消息队列：
- 每个房间对应一个 topic 或 routing key（如 room.chat.lobby）
- 各实例作为 consumer 订阅对应 topic，收到消息后查本地连接池 + Redis 成员表，只推给当前在线且在该房间的用户
- 比 Redis Pub/Sub 更重，但容错更强（比如某实例宕机，消息不会丢失）
客户端路由与连接粘性（可选优化）
虽然不是必须，但加一层负载均衡策略能减少跨实例通信压力：
- Nginx 或 API 网关按 roomId 或 userId 做一致性哈希，让同一房间用户尽量连到同一台实例
- 这样大部分广播在本机完成，只有新用户加入/跨实例踢人等少数操作才需 Redis 协调
- 注意：不能强依赖粘性——实例挂了要能自动漂移，所以底层状态仍必须集中托管
不复杂但容易忽略的是：房间生命周期管理。比如没人了要不要自动销毁 Redis 中的 room 数据？建议加定时扫描或用 Redis Key 过期 + 过期事件监听来清理空房间，避免内存泄漏。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
