WebSocket集群中UUID不能直接作全局连接ID，必须通过Redis的SET NX原子操作完成“用户ID+UUID+节点标识”三元组注册，关闭时需DEL+兜底清理，并校验EXISTS再投递消息。
websocket集群中无法靠单机内存维护连接唯一性，uuid本身不解决跨节点冲突——它只保证“生成时随机”，不保证“全局唯一注册”。真正需要的是：**在生成uuid后，立即通过分布式锁或原子写入完成一次“连接声明”**。
为什么直接用uuidv4()不能当全局连接ID
Node.js 的 uuidv4()、Java 的 UUID.randomUUID()、Go 的 uuid.NewUUID() 都是本地随机生成，无协调机制。集群下两台机器同一毫秒生成相同 UUID 的概率虽低（10⁻³⁶量级），但一旦发生，就会导致：
- Redis 中
user:123 → connection_id:A1B2和user:123 → connection_id:A1B2被重复覆盖 - 消息广播时，两个同 ID 连接被同时推送，或其中一个被误踢
- 心跳检测误判：A 节点发心跳，B 节点查不到该 ID，触发假断连清理
必须绑定会话生命周期的注册流程
连接建立后，不能仅存 connectionId，而要以「用户标识 + 连接ID + 节点标识」三元组完成一次原子注册。推荐使用 Redis 的 SET key value EX 300 NX 指令：
SET ws:conn:u123:abcde123 "node-02:ws-789" EX 300 NX
说明：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
u123是业务用户ID（如userId或sessionId） -
abcde123是本地生成的uuidv4()，仅作后缀防哈希碰撞 -
node-02:ws-789包含节点名和本机连接句柄，用于后续精准路由 -
NX确保首次写入成功才视为注册成功；失败则拒绝该连接，强制重试或返回 409
如何安全地销毁连接ID并避免残留
连接关闭时，仅删本地 Map 不够。必须同步清理 Redis 注册项，且需防止“已删注册但消息正路上”的竞态。正确做法是：
- 在
@OnClose（Java）或ws.on('close')（Node.js）中，先执行DEL ws:conn:u123:abcde123 - 同时启动一个 5 秒延迟的兜底任务（如 Redis Delayed Queue 或内存定时器），再次检查并清除残留
- 所有消息下发逻辑必须前置校验：
EXISTS ws:conn:u123:abcde123，不存在则跳过投递 - 禁止依赖
TTL自动过期——因为连接可能活跃超 5 分钟，但心跳异常时又需快速失效
客户端重连时如何复用旧连接ID（可选但推荐）
很多场景下，客户端网络抖动后应尽量复用原连接上下文（如未读计数、房间状态）。此时不应每次重连都生成新 uuidv4()，而是：
- 首次连接时由服务端生成并返回
connectionId，客户端持久化存储（localStorage / SharedPreferences） - 重连请求带上该
connectionId，服务端尝试SET ... NX；失败说明已被其他实例占用，再 fallback 到新 UUID - 配合 Redis 的
GETSET可实现“抢占式续期”，比纯SET NX更适合高并发重连场景
最易被忽略的一点：所有基于 UUID 的路由逻辑，必须默认接受「该 ID 当前无对应活跃连接」这一事实，并静默跳过，而不是抛异常或阻塞等待。集群环境下，连接状态永远是最终一致的，不是强一致的。
