WebSocketSession不可序列化，因其绑定JVM内I/O通道；Redis仅存token→节点ID等元数据，本地内存保留会话映射，通过Pub/Sub广播消息并由目标节点投递。
Spring Boot WebSocket 集群无法直接共享 WebSocketSession，因为它是不可序列化的内存对象；Redis 里存的不是 session 本身，而是连接元数据（如 token → 节点ID + 时间戳）和路由映射关系。
为什么不能把 WebSocketSession 直接塞进 Redis
Spring 的 WebSocketSession 是一个轻量级、生命周期绑定到当前 Tomcat/Jetty 实例的 Java 对象，内部持有 javax.websocket.Session 和 I/O channel 引用，无法被 JdkSerializationRedisSerializer 或 GenericJackson2JsonRedisSerializer 正确序列化。强行存会导致 NotSerializableException 或反序列化后变成无效句柄。
常见错误现象：java.io.NotSerializableException: org.apache.tomcat.websocket.WsSession 或服务重启后消息发不出、session.isOpen() 返回 false 却仍被误调用。
- 真正该存进 Redis 的是：用户标识（如
token）、当前连接所在节点标识（如serverId）、连接时间、是否活跃等轻量字段 - 本地内存仍需保留一份
ConcurrentHashMap，仅用于本节点内快速投递 - Redis 只承担“寻址”角色 —— 告诉你“这个用户现在连在哪台机器上”
Redis Pub/Sub 是跨节点转发消息的核心机制
当节点 A 想给 token="abc123" 的用户发消息，但该用户实际连在节点 B 上时，A 不会尝试远程调用 B 的 JVM，而是向 Redis 频道（如 ws:route:abc123）发布一条消息，节点 B 订阅该频道并收到后，再用本地缓存的 WebSocketSession 投递。
关键配置与代码要点：
- 订阅逻辑必须在 Spring 容器启动后立即注册，推荐用
@EventListener(ContextRefreshedEvent.class)触发redisTemplate.listen(...) - 频道名建议带前缀和粒度控制，例如
ws:user:{token}（精准）或ws:group:{groupId}（广播），避免全量扫描 - 不要依赖
MessageListenerAdapter默认的反射调用，它可能在反序列化失败时静默丢弃消息；应手动 try-catch 并记录SerializationException - 发送端务必设置 TTL 或使用 Redis Stream 替代 Pub/Sub，防止网络分区恢复后堆积过期消息
如何保证节点上线/下线时路由信息准确
节点启动时往 Redis 写入临时 key（如 ws:node:node-a:heartbeat），并开启定期刷新；节点关闭前主动删除该 key。其他节点通过 SCAN ws:node:*:heartbeat 或监听 key 过期事件感知存活状态。
由 ReMe 驱动的记忆管理系统，支持跨会话记忆持久化、自动应用用户偏好以及智能上下文压缩...
常见陷阱：
- 只写不删：进程 kill -9 导致 key 残留，新请求仍被路由到已死节点
- 心跳间隔 > Redis key 过期时间：造成频繁误判节点离线
- 用
SETNX注册但没配EX：key 永久存在，集群无法收敛 - 没做节点 ID 全局唯一校验：两个同名 node-b 同时写入，覆盖彼此心跳
推荐做法：节点启动时生成 UUID 作为 serverId，写入 redisTemplate.opsForValue().set("ws:node:" + serverId, "UP", 30, TimeUnit.SECONDS)，并启用 RedisExpirations 监听过期事件清理本地路由缓存。
ConcurrentHashMap 本地缓存必须配合连接有效性检查
即使 Redis 显示用户连在本节点，也不能无条件信任 WebSocketSession 仍可用 —— 客户端可能已断网、浏览器关闭、心跳超时但未触发 afterConnectionClosed。
实操建议：
- 每次发消息前调用
session.isOpen() && session.isActive()，失败则先从本地 map 移除，再触发一次 Redis 路由刷新 - 不要在
afterConnectionClosed中仅做 remove 操作，还要同步删除 Redis 中对应token → serverId映射（用DEL ws:route:{token}） - 对高频连接场景，可加一层 LRU 缓存（如
Caffeine）包裹 ConcurrentHashMap，避免 GC 压力过大 - 避免在
handleTextMessage中直接操作 session 发送响应 —— 若此时连接已断，会抛IllegalStateException: The session has been closed
最易被忽略的一点：Nginx 或 SLB 层必须开启 ip_hash 或基于 token 的 sticky session，否则 WebSocket 握手阶段就可能被轮询到不同节点，导致首次连接即路由错乱 —— 这个问题不在代码层，而在基础设施配置里。
