跨节点 websocket 会话需外部存储与显式路由：因各节点内存连接集隔离，仅靠 websockets 库无法同步；广播方案低效且有冗余开销；正确做法是 redis 存路由映射 + 定向投递 + 严格生命周期管理。
跨节点 WebSocket 会话状态无法自动同步，必须靠外部存储 + 显式路由机制来解决。直接依赖内存或本地变量必然导致消息丢失、用户收不到推送、状态不一致。
为什么不能只用 websockets 库自带的连接集合？
因为 websockets 的 connected 集合是纯内存结构，只在当前 Python 进程内有效。集群中每个服务实例都有一份独立的 connected，彼此完全隔离。
- 用户 A 连到 Node1，Node2 根本不知道这个连接存在
- 业务逻辑在 Node2 触发推送时，
for client in connected只遍历 Node2 自己的连接，A 永远收不到 - 即使你把用户 ID 存进 Redis，也不代表你知道该连在哪台机器上——除非额外记录节点标识
redis pub/sub 广播所有消息的代价是什么？
广播（publish to all）是最简单但最粗糙的做法：所有节点都收到每条消息，再各自判断“这条是否该推给我本地的某个 client”。它省去了路由查询步骤，但带来三个实际问题：
- 每条消息被每个节点重复消费，CPU 和网络带宽随节点数线性增长
- 必须在每个节点做“本地连接匹配”，比如用
user_id查websocket对象，这要求你在内存里维护一张{user_id: websocket}映射表（不是仅靠connected集合） - 如果某节点没连上用户，却仍要解析、反序列化、丢弃消息，属于无效开销
示例中常见错误写法：if user_id in local_user_websocket_map 判断前没加锁或没考虑连接已断开，容易引发 RuntimeError: cannot call recv() on a closed websocket。
怎么让消息只发给目标节点而不是全量广播？
核心是两步：先查路由，再定向投递。Redis 不只是用来 pub/sub，更要存映射关系：
- 连接建立时，Node1 执行：
redis.hset("ws:session", user_id, "node1:abc123")（abc123是该连接的唯一id） - 需要推送时，Node2 先
redis.hget("ws:session", user_id)，拿到"node1:abc123"，再决定发到哪个 Redis 频道，比如pubsub.publish("node1_broadcast", payload) - 每个节点启动时订阅自己的频道：
pubsub.subscribe(f"node{NODE_ID}_broadcast")
这样避免了无意义广播，但引入新负担：每次推送前多一次 Redis 查询（RTT），且需保证 hset 和连接建立/断开的原子性——推荐用 redis.eval() 脚本封装 set + expire + clean 逻辑，否则断连后残留的 session 映射会导致消息永远发错地方。
容易被忽略的连接生命周期管理细节
WebSocket 连接断开不像 HTTP 请求有明确结束点。超时、客户端崩溃、NAT 断连都会让服务端“以为还连着”，而 Redis 中的 session 映射若不及时清理，后续推送就彻底失效。
- 必须监听
websocket.close()或捕获ConnectionClosed异常，在 finally 块里删 Redis key - 不能只靠客户端发 close 帧——要加心跳检测：每 30 秒 ping，5 秒没 pong 就主动 close 并清理
- Redis 的 session key 必须设
EXPIRE，比如redis.hset("ws:session", user_id, node_info); redis.expire("ws:session", user_id, 60)，双重保险
这些动作一旦漏掉任意一环，集群就会出现“用户已掉线，但系统还在往旧节点疯狂发消息”的静默故障，极难排查。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
