基于Server-Side Events的分布式服务跨节点客户端通知问题

• 大量客户端连接至HTTP服务器集群
• 集群部署在负载均衡器后方，包含多个节点（如Node A、Node B等）
• 某客户端通过Server-Side Events（SSE）订阅事件流（接口为GET /event-stream），当前连接绑定在Node A上
• 该客户端发起一个异步重型任务请求（如POST /prepare-zip），被负载均衡器随机分发到Node B处理
• Node B完成任务后需要通知客户端，但只有Node A与该客户端保持着活跃的SSE连接

1. 全节点广播方案

   • 若用队列实现广播，所有节点都会轮询消费消息，大部分节点会因不是目标节点而丢弃消息，造成资源浪费
   • 模糊了HTTP请求处理与队列事件处理的职责边界，增加节点的复杂度和维护成本

2. 共享存储记录活跃连接方案

   • 需要频繁读写共享存储来维护连接状态，高并发场景下会成为性能瓶颈
   • 连接状态的一致性难以保证（比如客户端断开连接后，存储中的记录可能未能及时清理）

1. 基于连接标识的定向消息队列 #

• 客户端建立SSE连接时，生成唯一的连接ID（可由客户端提供或服务端生成），Node A在持有连接的同时，将该连接ID与自身节点标识绑定
• 客户端发起异步任务请求时，把这个连接ID携带在请求参数/Header中
• Node B完成任务后，根据连接ID找到对应的节点标识，直接向目标节点的专属队列发送通知消息
• Node A监听自己的专属队列，收到消息后立刻通过SSE连接推送给客户端
• 优势：避免无效广播，消息精准投递，职责清晰（HTTP节点只处理自身连接和专属队列）

2. 带主题过滤的分布式Pub/Sub集群 #

• 客户端建立SSE连接时，Node A以**客户端唯一标识（或连接ID）**为主题，订阅分布式Pub/Sub集群的对应频道
• 客户端发起异步任务时，携带该标识；Node B完成任务后，向这个特定主题发布通知消息
• 只有订阅了该主题的Node A会收到消息，随后推送给客户端
• 优势：无需维护节点与连接的绑定关系，Pub/Sub集群自动处理消息路由，扩展性强，适合大规模集群

3. 会话粘性+事件总线结合（适合特定场景） #

• 配置负载均衡器，对同一客户端的SSE连接和后续异步请求启用会话粘性（基于Cookie或客户端IP），确保两者都落到同一节点
• 节点内部通过本地事件总线处理任务完成后的通知，直接推送给本地持有的SSE连接
• 注意：该方案仅适合对会话粘性兼容性要求高的场景，若节点故障会导致连接丢失，需配合连接重连机制
• 优势：实现最简单，无跨节点通信成本，适合中小规模集群

内容的提问来源于stack exchange，提问作者mandark