SSE链接断开后如何实现自动重连？

Question

在使用SSE（Server-Sent Events）实现服务端消息推送时，网络波动或服务端重启常导致连接意外断开。尽管浏览器会自动尝试重连，但其默认行为受限于`eventSource`的`retry`参数且无法处理长时间不可用场景。常见问题是：当连接中断后，如何确保客户端在不同网络环境下稳定、有序地自动重连，并避免频繁请求造成资源浪费？同时，如何在重连时携带上下文信息（如用户身份或断点位置），防止消息丢失？开发者常忽视错误状态判断与重连退避策略，导致用户体验下降。

Answer 1

一、SSE连接中断的常见现象与底层机制

Server-Sent Events（SSE）是一种基于HTTP长连接的单向通信协议，允许服务端主动向客户端推送数据。其核心依赖于EventSource接口，在浏览器中创建持久连接。然而，当网络波动或服务端重启时，TCP连接可能意外中断。

• 浏览器会依据retry字段（单位：毫秒）进行重连尝试
• retry仅在接收到服务器明确设置时生效，否则使用默认值（通常为3秒）
• 若服务端长时间不可达，浏览器可能停止自动重连或触发错误事件
• 断开后，原有连接上下文丢失，无法恢复之前的消息流位置

此阶段开发者常误认为“浏览器自动重连”已足够，忽视了真实复杂网络环境下的稳定性问题。

二、连接状态判断与错误类型细分

SSE提供onerror回调，但该事件在多种异常场景下均会被触发，需通过上下文区分具体原因：

错误类型	可能原因	是否应立即重试
NETWORK_ERROR	网络中断、DNS失败	否（需退避）
SERVER_RESTART	503/504响应码	是（指数退避）
CONNECTION_LOST	TCP连接被RST/FIN关闭	视情况而定
PARSE_ERROR	非标准SSE格式返回	不应重连

精准识别错误类型是设计可靠重连策略的前提。例如，可通过检查event.target.readyState和响应头信息辅助判断。

三、实现智能重连机制：退避算法与状态管理

为避免频繁请求导致资源浪费，应采用指数退避（Exponential Backoff）结合随机抖动（Jitter）策略：

let retryCount = 0;
const maxRetries = 10;
const baseDelay = 1000; // 初始延迟1秒
const maxDelay = 30000; // 最大延迟30秒

function connect() {
  const es = new EventSource('/stream?userId=123&lastId=' + getLastMessageId());

  es.onerror = () => {
    if (retryCount >= maxRetries) {
      console.warn('达到最大重试次数，停止连接');
      return;
    }

    const delay = Math.min(baseDelay * Math.pow(2, retryCount), maxDelay);
    const jitter = delay * 0.2 * Math.random(); // 添加±20%抖动
    setTimeout(() => {
      retryCount++;
      connect();
    }, delay + jitter);
  };

  es.onmessage = (event) => {
    updateLastMessageId(event.lastEventId);
    retryCount = 0; // 成功接收消息，重置计数
  };
}

上述代码实现了基础的容错与退避逻辑，确保在网络不稳定时不会形成“雪崩式”请求风暴。

四、上下文保持与消息断点续传机制

SSE协议原生支持Last-Event-ID机制，服务端可通过HTTP响应头或事件中的id:字段标识每条消息唯一ID。客户端在重连时自动携带该ID至GET /stream?lastId={id}查询参数中。

1. 客户端存储最近成功处理的消息ID（如localStorage或内存变量）
2. 每次接收到新消息更新本地ID缓存
3. 重连URL中附加lastId参数
4. 服务端根据lastId从数据库或消息队列中恢复未送达消息
5. 使用有序消息存储结构（如Kafka分区、Redis Stream）保证顺序性
6. 对关键业务消息引入ACK确认机制，防止丢失

该机制有效解决了因连接中断导致的历史消息遗漏问题。

五、多层级健康检测与降级方案设计

graph TD
    A[客户端发起SSE连接] --> B{能否建立连接?}
    B -- 是 --> C[监听消息流]
    B -- 否 --> D[发起心跳探测API]
    D --> E{服务是否存活?}
    E -- 是 --> F[等待随机时间后重试SSE]
    E -- 否 --> G[切换至轮询模式]
    G --> H[定时调用REST API获取更新]
    H --> I{服务恢复?}
    I -- 是 --> J[重新尝试建立SSE连接]

在极端网络条件下，可引入降级机制：当连续多次SSE连接失败后，临时切换为短轮询方式维持基本通信能力，待网络恢复后再升回SSE模式。

六、服务端协同优化建议

客户端健壮性提升需配合服务端改进：

• 服务端应在重启后保留最近N条消息供客户端补拉
• 合理设置Connection: keep-alive与超时时间
• 通过retry: 5000显式控制客户端重试间隔
• 记录客户端IP/UserAgent用于连接追踪与限流
• 部署反向代理（如Nginx）时注意调整proxy_timeout等参数
• 使用负载均衡时启用Session Affinity或共享消息状态存储

只有全链路协同优化，才能构建真正高可用的实时推送系统。