WebSocket Session 无法序列化，故不能存入 Redis 共享；实际采用消息广播+本地查找机制，Redis 仅存业务数据，跨节点推送需本节点查 session 后发送。
WebSocket Session 无法序列化，根本不能“共享”到 Redis。所谓“同步 Session”，其实是绕过 Session 共享，改用消息广播 + 本地查找的协作机制。
为什么不能把 WebSocketSession 存进 Redis
Java 的 WebSocketSession 是一个包含 Session、Principal、NativeWebSocketSession 等强依赖当前 JVM 实例和 Netty Channel 的对象，内部持有不可序列化的资源引用（比如 ChannelHandlerContext）。强行序列化会抛 NotSerializableException 或运行时 NullPointerException。
所以所有声称“把 Session 存 Redis 实现共享”的方案，本质都是错的，或已失效（如旧版 Spring WebSocket 的 SessionRepositoryMessageInterceptor 已废弃）。
- Redis 只能存业务数据（如
userId、message、targetId） - 每个节点只负责处理自己内存中还存活的
WebSocketSession - 跨节点推送 = “发通知” + “本节点查 session + 发送”，不是“取 session + 发送”
stringRedisTemplate.convertAndSend() 怎么用才不丢消息
这是最轻量、最可控的发布方式，但要注意几个隐性约束：
- 频道名必须是字符串，建议统一前缀，例如
"ws:msg:chat"，避免和其他业务混用 - 发送内容推荐用 JSON 字符串（非 Java 对象），避免序列化器不一致导致订阅端解析失败
- 不要在 Web 层直接调用 —— 若请求线程被 Tomcat 回收而消息尚未真正写入 Redis，可能静默丢失；应交由
@Async或消息队列兜底 - 若需确认送达，得额外用 Redis Stream 或 ACK 机制，原生 Pub/Sub 不保证投递
示例发送逻辑：
stringRedisTemplate.convertAndSend("ws:msg:notify",
"{\"type\":\"ALERT\",\"userId\":1001,\"content\":\"订单已支付\"}");
监听端用 RedisMessageListenerContainer 还是 RTopic？
二者都能用，但行为差异明显：
-
RedisMessageListenerContainer（Spring Data Redis）：基于Jedis/Lettuce原生 Pub/Sub，启动即订阅，无自动重连，异常中断后需手动恢复监听 -
RTopic（Redisson）：封装了自动重连、集群拓扑感知、支持 Kryo/JSON 序列化，publishAsync()返回RFuture可链式处理，更适合生产环境 - 若用
RTopic，务必让每个节点订阅**同一个频道**（如"ws:broadcast"），而不是按 node 名分 channel —— 否则变成单点推送，失去集群意义
典型误用：
// ❌ 错：每个节点监听自己专属 channel，消息只发给本节点
RTopic topic = redisson.getTopic("ws:node:" + nodeName); // 无效广播
监听回调里做 session 推送的三个硬限制
这是最容易引发线程阻塞、连接泄漏、OOM 的环节：
- 回调必须是轻量级的 —— 只做
Map<String, WebSocketSession>查找 +session.isOpen() && session.isOpen()校验，不做数据库查询、HTTP 调用、日志慢写入 - 发送必须异步：用
session.sendMessage(new TextMessage(payload))后立即返回，别等Future；否则阻塞 Redis 监听线程池（默认单线程） - session 缓存必须用线程安全结构（如
ConcurrentHashMap），且要定期清理过期 session（Netty 关闭后不会自动移除）
关键校验不能少：
if (session != null && session.isOpen() && !session.isClosed()) {
session.sendMessage(new TextMessage(msgJson));
}
真正的难点不在“怎么发”，而在“怎么确保每条消息都找到对应 session 并成功发出”——这需要 session 生命周期管理、异常降级策略（如退化为轮询拉取）、以及对 Netty 异步写入失败的捕获与重试。这些细节一旦漏掉，集群推送就变成概率性成功。
