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

Question

在使用SSE（Server-Sent Events）实现服务端消息推送时，网络波动或服务重启常导致连接中断。尽管SSE协议内置了自动重连机制（通过`EventSource`的`reconnect`事件和`retry`字段），但实际应用中仍存在重连失败、重复消息或事件丢失等问题。一个常见问题是：当服务端短暂不可用或客户端处于离线状态时，浏览器的`EventSource`可能无法成功重建连接，且不触发预期的重连逻辑。如何在前端正确监听错误事件、合理设置重试间隔，并结合心跳机制判断连接状态，以实现稳定可靠的自动重连？

Answer 1

构建高可用的SSE连接：从基础机制到稳定重连策略

1. SSE自动重连机制的基础原理

Server-Sent Events（SSE）是一种基于HTTP的单向通信协议，允许服务端向客户端推送实时消息。其核心对象是浏览器中的 EventSource API，它天然支持自动重连机制。

当连接断开时，EventSource 会根据服务器响应头中的 retry 字段或默认延迟（通常为3秒）尝试重新连接。服务器可通过发送如下格式的消息来控制重试时间：

: retry: 5000
data: Hello, client!

该机制依赖于网络层和浏览器行为，但在复杂网络环境或服务不可用场景下，原生机制往往不足以保障连接稳定性。

2. 常见问题分析：为何重连失败或未触发？

• 网络短暂中断但未触发 error 事件：某些代理或中间件可能静默丢包，导致连接“假死”。
• 服务重启期间无响应：若服务完全宕机，TCP连接无法建立，EventSource 可能长时间等待超时。
• 重复消息与事件丢失：缺乏消息ID机制时，重连后无法判断是否已接收最新数据。
• 浏览器限制重试次数或策略不灵活：部分浏览器对重连频率有限制，且不暴露细粒度控制接口。

3. 前端错误监听与重试间隔优化

要实现可靠的重连逻辑，必须正确监听 error 事件，并结合指数退避算法动态调整重试间隔。

const eventSource = new EventSource('/stream');

eventSource.addEventListener('error', (event) => {
    console.warn('SSE connection error:', event);
    
    // 防止无限重连
    if (reconnectAttempts > MAX_RECONNECT_ATTEMPTS) {
        console.error('Max reconnection attempts reached');
        return;
    }

    // 指数退避 + 随机抖动
    const delay = Math.min(1000 * Math.pow(2, reconnectAttempts) + Math.random() * 1000, 30000);
    setTimeout(() => {
        reconnect();
        reconnectAttempts++;
    }, delay);
});

4. 心跳机制设计：主动探测连接状态

SSE本身无心跳帧定义，但可通过服务端定期发送 ping 消息模拟：

: ping
data: \n
id: ping-1718923456

前端可记录最后一次收到消息的时间戳，结合定时器判断是否“失联”：

心跳周期	超时阈值	处理动作
15s	45s	触发手动重连
20s	60s	关闭并重建 EventSource
30s	90s	上报监控日志

5. 客户端连接状态管理模型

引入状态机管理连接生命周期，提升可维护性：

const STATES = {
    IDLE: 'idle',
    CONNECTING: 'connecting',
    OPEN: 'open',
    CLOSED: 'closed',
    RECONNECTING: 'reconnecting'
};

状态转换流程图如下：

graph TD
            A[Idle] --> B[Connecting]
            B --> C{Connected?}
            C -->|Yes| D[Open]
            C -->|No| E[Reconnecting]
            D --> F[Error or Timeout]
            F --> E
            E --> G[Wait with Backoff]
            G --> B
            F --> H[Closed - Max Attempts]

6. 消息去重与断点续传机制

为避免重复消费，服务端应在每条消息中包含唯一ID：

id: msg-12345
event: user_update
data: {"user":"alice","status":"online"}

前端使用 Set 或 IndexedDB 缓存已处理的消息ID，防止重复执行业务逻辑。

7. 综合解决方案示例代码

class ReliableEventSource {
        constructor(url, options = {}) {
            this.url = url;
            this.maxRetries = options.maxRetries || 10;
            this.heartbeatInterval = options.heartbeatInterval || 15000;
            this.timeoutThreshold = options.timeoutThreshold || 45000;

            this.reconnectAttempts = 0;
            this.lastMessageTime = Date.now();
            this.processedIds = new Set();
            this.state = 'idle';
            this.heartbeatTimer = null;

            this.connect();
        }

        connect() {
            this.state = 'connecting';
            this.source = new EventSource(this.url);

            this.source.onopen = () => {
                this.state = 'open';
                this.reconnectAttempts = 0;
                this.lastMessageTime = Date.now();
                this.startHeartbeatCheck();
            };

            this.source.onmessage = (event) => {
                if (event.data === '') return; // 忽略空ping

                if (event.lastEventId && this.processedIds.has(event.lastEventId)) {
                    return; // 去重
                }

                this.lastMessageTime = Date.now();
                if (event.lastEventId) {
                    this.processedIds.add(event.lastEventId);
                }
                // 触发业务事件
                this.dispatchEvent(event);
            };

            this.source.onerror = () => {
                this.handleConnectionError();
            };
        }

        startHeartbeatCheck() {
            clearInterval(this.heartbeatTimer);
            this.heartbeatTimer = setInterval(() => {
                if (Date.now() - this.lastMessageTime > this.timeoutThreshold) {
                    console.warn('Heartbeat timeout, forcing reconnect');
                    this.handleConnectionError();
                }
            }, this.heartbeatInterval);
        }

        handleConnectionError() {
            if (this.reconnectAttempts >= this.maxRetries) {
                this.state = 'closed';
                clearInterval(this.heartbeatTimer);
                return;
            }

            this.state = 'reconnecting';
            this.source.close();
            const delay = Math.min(1000 * Math.pow(2, this.reconnectAttempts) + Math.random() * 1000, 30000);
            setTimeout(() => {
                this.reconnectAttempts++;
                this.connect();
            }, delay);
        }

        dispatchEvent(event) {
            // 自定义事件分发逻辑
            console.log('Received:', event.data);
        }
    }

8. 监控与可观测性增强

在生产环境中，应集成以下监控能力：

• 记录每次重连耗时与失败原因
• 上报连接状态变化至日志系统（如ELK或Sentry）
• 通过 Performance API 分析首次连接延迟
• 结合用户地理位置与网络类型做异常归因

9. 替代方案对比：SSE vs WebSocket vs Long Polling

方案	双向通信	自动重连	消息顺序	适用场景
SSE	否	内置但弱	保证	服务端推送为主
WebSocket	是	需手动实现	保证	实时交互应用
Long Polling	模拟	依赖轮询	依赖实现	兼容老旧环境

10. 最佳实践总结建议

1. 始终监听 error 事件并实现自定义重连逻辑
2. 采用指数退避 + 抖动策略避免雪崩
3. 服务端定期发送心跳消息维持连接活性
4. 使用消息ID实现幂等处理
5. 前端维护连接状态机以提升可调试性
6. 设置最大重连次数防止资源泄漏
7. 结合 RUM（Real User Monitoring）工具追踪连接质量
8. 在 Service Worker 中托管 SSE 连接以延长生命周期
9. 考虑降级方案（如 fallback 到 polling）
10. 文档化重连行为以便团队协作理解