websocketsession不可序列化是设计限制，因其持有tcp连接等jvm特有资源；正确方案是本地内存管理会话+redis pub/sub广播消息，各节点监听后按需推送。
WebSocket Session 无法跨节点同步，不是配置问题，而是设计限制 —— WebSocketSession 对象本身不可序列化，任何试图把它存进 Redis、MySQL 或通过 gRPC 传给其他节点的做法都会失败。
为什么不能直接序列化 WebSocketSession
它内部持有了底层 TCP 连接、线程上下文、Servlet 容器引用等 JVM 特定资源，这些对象在反序列化时无法重建连接状态。强行序列化会导致 NotSerializableException 或运行时 NullPointerException。Spring Boot 的 StandardWebSocketSession 和 Tomcat 的 WsSession 都明确不实现 Serializable 接口。
- 即使你用
@EnableWebSocketMessageBroker+ STOMP，SimpMessageSendingOperations.convertAndSendToUser()也只在单节点内有效 - Redis 存储
sessionId → userId映射可行，但绝不能存WebSocketSession实例本身 - 集群中每个节点必须只管理自己建立的连接，这是底线
正确做法：本地会话 + Redis Pub/Sub 广播
消息发送方不找目标 session，而是广播；所有节点监听频道，各自判断“这条消息是否该推给我本地的某个用户”。这是目前 Spring Boot 2.7+ JDK 8 下最稳定、零依赖 MQ 的方案。
- 每个节点用
ConcurrentHashMap<string websocketsession></string>管理本机连接（保留你原有逻辑） - 发送消息前，查 Redis 获取目标
userId对应的所有sessionId（可选），但更推荐直接广播 + 本地过滤 - 用
redisTemplate.convertAndSend("ws:topic:msg", payload)发布消息 - 每个节点订阅
"ws:topic:msg"，收到后遍历本地WebSocketSession，用session.getAttributes().get("userId")匹配再推送
gRPC 或 HTTP 节点间直连转发？慎用
像 gowebsocket 那样用 gRPC 让 A 节点调 B 节点的接口去发消息，看似精准，实则引入新风险：
- 节点下线或网络抖动时，
gRPC UNAVAILABLE导致消息丢失，需重试+持久化，复杂度陡增 - HTTP 转发（如
RestTemplate调用另一节点的/ws/push）同样面临超时、重试、幂等难题 - 相比 Pub/Sub 的“尽力送达+本地兜底”，直连模式把可靠性压力全压在通信链路上
Nginx 配置必须开启 sticky session（IP Hash）
这不是可选项，是避免消息乱序和重复连接的前提。WebSocket 握手是 HTTP 升级请求，Nginx 必须保证同一用户的后续帧始终打到同一台后端节点：
upstream ws_backend {
ip_hash; # 关键！不能用 round-robin
server 10.0.1.10:8089;
server 10.0.1.11:8089;
}
- 若用
least_conn或hash $cookie_jsessionid，用户重连可能落到新节点，旧 session 已失效，造成“已登录却收不到消息” - SSL 终结在 Nginx 时，
wss://请求仍走 IP Hash，无需额外透传 header - 此配置仅保障连接粘性，不解决跨节点消息分发 —— 广播逻辑仍不可少
真正容易被忽略的是：广播消息体里必须携带 userId 和 messageId，否则多个节点同时推送会造成客户端重复渲染；而 messageId 的去重必须在前端做，后端只负责投递一次。
