目录
[从零到一：构建高可用分布式 Server-Sent Events (SSE) 实时推送系统](#从零到一：构建高可用分布式 Server-Sent Events (SSE) 实时推送系统)
[一、 为什么选择 SSE？](#一、 为什么选择 SSE？)
[二、 核心原理：基于文本流的魔法](#二、 核心原理：基于文本流的魔法)
[三、 进阶：分布式架构设计（Redis Pub/Sub）](#三、 进阶：分布式架构设计（Redis Pub/Sub）)
[四、 生产环境的避坑指南](#四、 生产环境的避坑指南)
[1. HTTP/1.1 的连接限制](#1. HTTP/1.1 的连接限制)
[2. 离线消息丢失](#2. 离线消息丢失)
[3. Nginx 缓存问题](#3. Nginx 缓存问题)
[五、 总结](#五、 总结)
从零到一：构建高可用分布式 Server-Sent Events (SSE) 实时推送系统
前言
在实时交互日益增长的今天（如 AI 聊天流式响应、实时金融行情、社交通知），开发者常在 WebSocket 和轮询之间挣扎。然而，对于 Server-to-Client 的单向数据流场景，HTML5 标准中的 SSE (Server-Sent Events) 凭借其轻量、原生重连、HTTP 兼容等特性，成为了"真香"选择。
本文将带你深度剖析 SSE，并分享如何利用 Redis 构建一套可横向扩展的分布式推送架构。
一、 为什么选择 SSE？
在实时通信方案中，SSE 处于一个非常精妙的平衡点：
| 特性 | 短/长轮询 | WebSocket | SSE |
|---|---|---|---|
| 实时性 | 延迟高 | 极高 (双向) | 高 (单向) |
| 协议 | HTTP | 独立的 TCP (WS) | 标准 HTTP |
| 重连机制 | 无 | 需手动实现 | 浏览器原生自带 |
| 开发难度 | 简单 | 复杂 | 极简 |
核心优势： SSE 运行在常规 HTTP 端口上，无需特殊防火墙配置，且默认支持断线重连，这让它在处理 AI 流式输出或消息通知时表现极佳。
二、 核心原理：基于文本流的魔法
SSE 的本质是服务器通过设置 Content-Type: text/event-stream，建立一个持久化的 HTTP 连接。
数据协议格式
服务器输出的每一条消息都必须以 data: 开头，以两个换行符 \n\n 结尾：
Plaintext
id: 1001
event: message
data: {"user": "Gemini", "content": "你好！"}三、 进阶：分布式架构设计（Redis Pub/Sub）
在单机模式下，我们只需在内存中维护一个 UserId -> Response 的 Map 即可推送。但在生产环境的分布式集群中，用户 A 可能连在 Server 1，而推送指令由 Server 2 发出。
为了打破"状态"限制，我们引入 Redis 发布/订阅 机制。
架构逻辑图
核心实现代码 (Node.js)
JavaScript
const express = require('express');
const Redis = require('ioredis');
const app = express();
const pub = new Redis(); // 用于发布消息
const sub = new Redis(); // 用于订阅频道
const localClients = {}; // 存储当前服务器持有的连接
// SSE 入口
app.get('/events', async (req, res) => {
const { userId } = req.query; // 建议从 JWT 中获取
res.writeHead(200, {
'Content-Type': 'text/event-stream',
'Cache-Control': 'no-cache',
'Connection': 'keep-alive'
});
// 1. 注册本地连接
localClients[userId] = res;
// 2. 订阅 Redis 频道
sub.subscribe(`user_channel:${userId}`);
req.on('close', () => {
delete localClients[userId];
console.log(`User ${userId} disconnected`);
});
});
// 3. 全局监听 Redis 消息并下发
sub.on('message', (channel, message) => {
const userId = channel.split(':')[1];
if (localClients[userId]) {
localClients[userId].write(`data: ${message}\n\n`);
}
});四、 生产环境的避坑指南
1. HTTP/1.1 的连接限制
在旧的 HTTP/1.1 下，浏览器对同一个域名有 6 个并发连接限制。这意味着如果用户多开标签页，SSE 可能会卡死。
- 对策 ：全面开启 HTTP/2，它可以多路复用，轻松支持数百个并发流。
2. 离线消息丢失
Redis Pub/Sub 是"发后即忘"的。如果用户短暂断网，推送就会丢失。
- 对策 ：配合
Last-Event-ID。客户端重连时会发送该 ID，服务端根据 ID 从 Redis Stream 或数据库中补发表之后的消息。
3. Nginx 缓存问题
如果你使用 Nginx 做反向代理，务必关闭 proxy_buffering，否则消息会被缓存，无法实时推送到前端。
Nginx
proxy_set_header Connection '';
proxy_http_version 1.1;
chunked_transfer_encoding off;
proxy_buffering off;
proxy_cache off;五、 总结
SSE 是一项被低估的技术。它简单、优雅且符合 Web 标准。通过 Redis Pub/Sub，我们能够轻松构建出支持横向扩展的分布式推送系统。
在构建诸如 智能助理、实时报表、在线协作 等应用时，SSE 往往是比 WebSocket 更加高效的选择。
博主结语：
希望这篇深度解析能帮你解决实时推送的架构难题。如果你对如何实现 AI 打字机效果的前端流式解析 感兴趣，欢迎在评论区留言，我们下期再见！
