Redis Pub/Sub精准推送需用户维度频道命名，如“ws:user:10086:notify”；连接绑定须在认证后完成，并设TTL；发消息前须查Hash获取在线节点再定向publish；C++中需用异步Redis客户端避免阻塞ASIO事件循环。
Redis Pub/Sub 频道命名必须绑定用户维度，不能只用固定频道名
很多人一上来就写 redis.publish("ws:all", msg)，结果所有节点都收到、所有用户都收到——这还是广播，不是精准推送。真正跨服务器定向的关键，在于频道名要能表达“目标用户是谁”。常见错误是把频道设计成服务级（如 "ws:server:node1"）或功能级（如 "ws:notify"），这样无法做用户粒度路由。
正确做法是：频道名 = 用户标识 + 业务类型，例如 "ws:user:10086:notify" 或 "ws:user:10086:order"。每个 WebSocket 节点启动时，订阅自己关心的频道前缀（比如用 PSUBSCRIBE ws:user:*:*），但实际消费时靠消息体里的 userId 字段二次过滤，避免误投。
注意：PSUBSCRIBE 支持通配符，但 Redis 官方不建议在生产环境高频使用大量模糊匹配（性能下降明显）。更稳的方案是节点启动后，动态 SUBSCRIBE 明确的频道列表，频道列表从 Redis Set 中读取（如 SMEMBERS ws:active_users），再拼出具体频道名。
WebSocket 连接与用户 ID 的绑定时机必须在握手完成之后、首次消息之前
在 C++ websocket++ 中，on_open 回调里拿到的是原始 connection_ptr，此时 HTTP 握手刚结束，但你还拿不到用户身份。如果这时就往 Redis 写映射关系，大概率会写入空 userId 或默认值，后续消息全发错。
立即学习“C++免费学习笔记（深入）”；
必须等客户端发来第一条带认证信息的消息（比如 JWT token 或 session id），在 on_message 里解析并验证，确认通过后再执行两步操作：
- 本地缓存：用
std::unordered_map<:string connection_ptr></:string>存userId → conn，key 是userId，value 是连接指针 - Redis 注册：用
SET ws:user:10086:host1:conn_abc123 "2026-10-21T08:25:00Z" EX 300，带 TTL 防止僵尸连接长期占位 - 同时向频道
ws:user:10086:join发一条轻量心跳消息，通知其他节点“此人已上线”，用于状态同步
漏掉 TTL 是常见坑：没过期时间的 key 会越积越多，某天运维清 Redis 时突然发现所有用户都收不到消息——因为映射还在，但连接早断了。
发送消息时不能直接 publish，必须先查 Redis 确认用户当前在线节点
假设你要给用户 10086 推送订单更新，流程不是“直接 PUBLISH ws:user:10086:order ...”，而是三步走：
第一步：查 KEYS ws:user:10086:*？不行，KEYS 是阻塞命令，集群中严禁使用。应该用 SCAN 配合模式 ws:user:10086:*，或更推荐——把所有该用户的连接信息统一存在一个 Hash 里：HGETALL ws:user:10086:sessions，字段为 node1:conn_a、node2:conn_b，值为最后活跃时间戳。
第二步：遍历这个 Hash，对每个 nodeX:conn_y 构造唯一频道名，比如 ws:node:node1:conn:conn_a，然后 PUBLISH 到该频道。这样消息只会被 node1 消费，且只推给 conn_a。
第三步：如果 Hash 为空，说明用户当前不在线，按业务策略决定是否存离线消息（比如写入 LPUSH ws:user:10086:offline ...）。
跳过第一步直接 publish 到用户频道，会导致：用户在 node1，你却往 node2 的频道发，node2 收到后本地找不到该连接，消息静默丢弃——连日志都难排查。
websocket++ 没有内置 Redis 客户端，必须选对异步集成方式
websocket++ 是纯头文件库，不带网络 I/O 抽象层，它用的是 ASIO。而主流 C++ Redis 客户端（如 redis-plus-plus）默认是同步阻塞模型，直接在 on_message 里调用会卡住整个 event loop，连接数一多就雪崩。
可行方案只有两个：
- 用
redis-plus-plus的异步接口（需开启REDIS_PLUS_PLUS_HAS_ASYNC_REDIS宏），配合 ASIO 的post或dispatch把回调扔进 websocket++ 的 IO 上下文 - 换用
cpp_redis（已归档但稳定）或自研极简异步 client，只封装publish/subscribe/hgetall几个关键命令，用async_write+async_read直接对接 ASIO
千万别在 on_open 或 on_message 里开新线程去调 Redis 同步接口——线程间传递 connection_ptr 极易引发 use-after-free，websocket++ 的连接对象生命周期完全由 ASIO 控制，外部线程根本不敢碰。
最隐蔽的坑是：本地测试一切正常，一上压测环境就频繁触发 connection closed abnormally 错误，十有八九是 Redis 调用阻塞导致 ASIO timer 超时，进而触发强制断连。
