WebSocket跨服务器通信需依赖Redis Pub/Sub实现：各节点独立维护连接，通过发布/订阅频道广播消息，消息格式为含type、roomId等字段的JSON，注意即发即弃特性及序列化一致性。
WebSocket 本身不支持跨服务器通信，要实现多台应用服务器（如 Node.js、Java、Go 等）之间共享实时消息，需借助外部消息中间件。Redis 的 Pub/Sub 机制轻量、低延迟、天然支持广播，是 WebSocket 跨服通信最常用且实用的桥梁。
核心架构逻辑
用户连接到任意一台 WebSocket 服务节点，该节点负责收发本机连接的消息；当需要向“全集群”广播时，消息先发布到 Redis 频道；其他所有 WebSocket 服务节点都订阅相同频道，收到后将消息分发给各自管理的客户端连接。
关键点：WebSocket 连接生命周期由各服务节点独立维护，Redis 只传递消息内容，不参与连接管理或状态同步。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
服务端需实现的两个角色
-
发布者（Publisher）：当某客户端发送消息（如聊天、通知），当前 WebSocket 服务节点解析后，调用
redis.publish("ws:global", message)向频道推送，不直接触达其他节点的连接。 -
订阅者（Subscriber）：每个服务节点启动时，建立独立的 Redis 订阅连接，监听如
ws:global或按业务细分的频道（如ws:room:1001），收到消息后遍历本地活跃连接，按规则（如房间 ID、用户 ID）筛选并推送。
频道设计与消息格式建议
避免所有消息挤在单个频道造成广播风暴。推荐分层命名：
立即学习“前端免费学习笔记（深入）”；
- 全局通知：
ws:notify:all - 房间广播：
ws:room:{roomId}（如ws:room:205） - 用户私信：
ws:user:{userId}（需各节点维护userId → socketId → serverId映射，或改用点对点消息队列）
消息体建议用 JSON，含必要元字段：
{
"type": "chat",
"roomId": "205",
"from": "u_8892",
"content": "你好",
"ts": 1717023456789
}
注意事项与常见坑
- Redis Pub/Sub 是“即发即弃”模型：若订阅连接断开，期间消息完全丢失——不适合需要可靠投递的场景（此时应改用 Redis Streams 或 Kafka）。
- 各 WebSocket 服务节点必须使用相同的序列化/反序列化逻辑，尤其注意时间戳、布尔值、空值等 JS 与其他语言的类型差异。
- 不要在订阅回调中执行耗时操作（如查 DB、调远程 API），否则会阻塞整个 Redis 订阅线程，导致消息积压；应转为异步任务或消息队列消费。
- 心跳与连接清理需在本地完成，Redis 不感知客户端上下线——上线/下线事件仍需通过各节点主动上报（如写入 Redis Hash 或使用 Redis 的
SETNX + EXPIRE做服务发现）。
