1. 为什么要在长轮询和SSE之间做选择做实时消息推送的开发者几乎都绕不开一个经典问题服务端有数据更新时怎么第一时间告诉浏览器早期大家用短轮询前端每隔几秒发一次请求问“有没有新数据”实现简单但浪费严重——大部分请求都是空手而归服务端压力大实时性还差。后来有人用长轮询请求发出去后服务端不立刻返回而是hold住连接等有数据了再响应前端收到响应后马上再发一个请求如此循环。长轮询比短轮询省资源但每次数据到达后都要重新建立请求HTTP头反复传输连接开销依然存在。SSEServer-Sent Events是另一条路。它基于HTTP长连接服务端可以持续向客户端单向推送文本数据浏览器端用EventSource接口接收断线还能自动重连。SSE的定位很明确服务端到客户端的单向实时推送。它不像WebSocket那样支持双向通信但胜在协议简单、基于纯HTTP、浏览器原生支持、自带重连机制特别适合通知、日志流、进度更新、行情推送这类场景。这个项目标题“基于长轮询的SSE”核心思路是把长轮询的“hold住连接等数据”和SSE的“持续推送”结合起来。实际落地时很多团队并不是直接用标准SSE而是用长轮询的机制去模拟SSE的效果或者在SSE连接上叠加长轮询的兜底逻辑。为什么这么做因为标准SSE在某些代理、网关、老旧浏览器环境下会被缓冲或断开而长轮询的兼容性更好。两者结合既能拿到SSE的实时性又能用长轮询兜底保证消息不丢。这篇文章适合谁看如果你正在做实时消息推送、后台任务进度反馈、在线协作通知、监控告警面板或者你被WebSocket的复杂度和连接管理折磨过想找一个更轻量的方案那这篇内容可以直接抄作业。我会从设计思路、协议细节、代码实现、参数调优、问题排查几个维度把“基于长轮询的SSE”这套方案拆开讲透。2. 长轮询与SSE的核心机制拆解2.1 长轮询到底“长”在哪里长轮询的本质是服务端延迟响应。客户端发起一个普通HTTP请求服务端收到后不立即返回而是把请求挂起直到以下三种情况之一发生有新数据可推、等待超时、连接断开。一旦响应返回客户端立刻发起下一次长轮询请求形成“请求-挂起-响应-再请求”的循环。这里的关键参数是超时时间。设得太短退化成短轮询浪费请求设得太长服务端要维护大量挂起连接内存和文件描述符压力大。常见做法是30秒到60秒。以30秒为例如果这30秒内有数据服务端立刻返回如果没有30秒后返回一个空响应客户端再发起新一轮。这样平均每个客户端每30秒至少产生一次请求比短轮询每秒一次要省得多。长轮询的另一个重点是连接管理。服务端需要维护一个“等待队列”每个挂起的请求对应一个等待者。当数据产生时从队列中取出等待者写入响应并关闭连接。这里要处理并发安全、超时清理、客户端断线检测等问题。用Servlet 3.0的异步支持或者Netty这类NIO框架可以避免线程被阻塞。2.2 SSE的协议格式与浏览器行为SSE的协议非常简洁。服务端返回的Content-Type必须是text/event-stream响应体是一系列以\n\n分隔的事件块。每个事件块可以包含以下字段data:消息内容可以多行每行一个dataevent:自定义事件类型默认是messageid:事件ID用于断线重连时通过Last-Event-ID头告诉服务端从哪继续retry:重连等待毫秒数一个典型的事件块长这样id: 1001 event: price-update data: {symbol:ABC,price:123.45}浏览器端用new EventSource(/stream)建立连接然后监听message事件或自定义事件。EventSource会自动处理重连如果连接断开浏览器默认等待约3秒后重新发起请求并带上Last-Event-ID头。服务端可以根据这个ID决定从哪条消息开始补发。SSE的优点是单向、轻量、原生支持。缺点是浏览器对同一域名的HTTP/1.1连接数有限制通常6个如果开多个SSE连接会占满。HTTP/2下多路复用可以缓解但代理和网关对SSE的缓冲行为经常导致消息延迟。2.3 两者结合的设计动机标准SSE在理想环境下工作良好但实际生产环境有几个坑Nginx默认会缓冲响应导致消息不实时某些企业代理会切断长连接老旧浏览器不支持EventSource。长轮询的兼容性几乎无敌任何能发HTTP请求的环境都能用。“基于长轮询的SSE”通常有两种实现形态。第一种是SSE为主长轮询兜底优先用EventSource如果检测到不支持或连接异常降级为长轮询。第二种是用长轮询模拟SSE语义服务端提供长轮询接口客户端封装一个类似EventSource的对象内部用长轮询循环实现持续接收对外暴露onmessage等接口。第二种更常见于需要统一兼容性的场景。选择这种混合方案的理由很直接实时性、兼容性、实现成本三者平衡。WebSocket实时性最好但需要独立协议升级、连接管理复杂、部分代理不支持纯SSE简单但环境依赖强纯长轮询兼容好但每次重建连接有开销。混合方案在SSE可用时用SSE不可用时自动切换长轮询客户端代码几乎不用改。3. 服务端实现从连接挂起到事件推送3.1 长轮询接口的设计与超时控制先看长轮询接口。假设我们用Java Servlet 3.0的异步能力来实现。核心是一个AsyncContext把请求挂起然后注册到等待队列。WebServlet(urlPatterns /poll, asyncSupported true) public class LongPollServlet extends HttpServlet { private final WaitQueue waitQueue WaitQueue.getInstance(); private static final long TIMEOUT_MS 30_000L; protected void doGet(HttpServletRequest req, HttpServletResponse resp) { AsyncContext async req.startAsync(); async.setTimeout(TIMEOUT_MS); String clientId req.getParameter(clientId); String lastId req.getParameter(lastEventId); Waiter waiter new Waiter(clientId, lastId, async); waitQueue.add(waiter); async.addListener(new AsyncListener() { public void onTimeout(AsyncEvent event) { waitQueue.remove(waiter); writeResponse(async, 204, ); } public void onError(AsyncEvent event) { waitQueue.remove(waiter); } public void onComplete(AsyncEvent event) { waitQueue.remove(waiter); } }); } }这里有几个关键点。超时时间设为30秒通过async.setTimeout设置。超时后返回204 No Content客户端收到后立即发起下一次请求。等待队列用ConcurrentHashMap或LinkedBlockingQueue实现按clientId分组支持按lastEventId过滤。异步监听器负责在超时、出错、完成时清理等待者防止内存泄漏。当有新数据产生时业务代码调用waitQueue.notify(clientId, event)从队列中取出该客户端的所有等待者写入响应并完成异步上下文。写入格式可以是JSON客户端解析后处理。注意长轮询接口必须设置Cache-Control: no-cache和Connection: keep-alive避免中间层缓存空响应。同时要限制单客户端并发挂起数防止恶意请求占满连接。3.2 SSE端点的建立与事件格式化SSE端点用标准方式实现。设置响应头然后保持连接打开持续写入事件块。WebServlet(urlPatterns /sse, asyncSupported true) public class SseServlet extends HttpServlet { private final SseEmitterManager emitterManager SseEmitterManager.getInstance(); protected void doGet(HttpServletRequest req, HttpServletResponse resp) { resp.setContentType(text/event-stream); resp.setCharacterEncoding(UTF-8); resp.setHeader(Cache-Control, no-cache); resp.setHeader(Connection, keep-alive); resp.setHeader(X-Accel-Buffering, no); AsyncContext async req.startAsync(); async.setTimeout(0); // 不超时由客户端或服务端主动关闭 String clientId req.getParameter(clientId); String lastEventId req.getHeader(Last-Event-ID); SseClient client new SseClient(clientId, async, lastEventId); emitterManager.register(client); // 如果有Last-Event-ID补发遗漏事件 if (lastEventId ! null) { ListEvent missed eventStore.getAfter(clientId, lastEventId); for (Event e : missed) { client.send(e); } } } }事件格式化方法public void send(Event event) { StringBuilder sb new StringBuilder(); if (event.getId() ! null) { sb.append(id: ).append(event.getId()).append(\n); } if (event.getType() ! null) { sb.append(event: ).append(event.getType()).append(\n); } String[] lines event.getData().split(\n); for (String line : lines) { sb.append(data: ).append(line).append(\n); } sb.append(\n); async.getResponse().getWriter().write(sb.toString()); async.getResponse().getWriter().flush(); }X-Accel-Buffering: no这个头很关键它告诉Nginx不要缓冲SSE响应。没有这个头Nginx会攒够一定字节才发送导致消息延迟。另外每次写入后必须flush否则数据留在缓冲区。3.3 统一事件总线与消息分发长轮询和SSE两套接口需要共享同一个事件源。设计一个事件总线业务模块产生事件后发布到总线总线根据客户端订阅关系分发给SSE连接和长轮询等待者。public class EventBus { private final SseEmitterManager sseManager; private final WaitQueue waitQueue; private final EventStore eventStore; public void publish(String clientId, Event event) { eventStore.save(clientId, event); // 推给SSE连接 SseClient sseClient sseManager.get(clientId); if (sseClient ! null) { sseClient.send(event); } // 唤醒长轮询等待者 waitQueue.notify(clientId, event); } }EventStore用于持久化最近的事件支持按lastEventId补发。可以用内存环形缓冲区也可以用Redis List。内存方案简单但重启丢数据Redis方案可靠但多一次网络往返。根据业务对可靠性的要求选择。消息分发时要考虑顺序性。同一客户端的事件必须按产生顺序推送否则前端状态会乱。可以用单线程分发或者按clientId哈希到固定线程。SSE的写入是同步的天然有序长轮询每次响应一个事件客户端按顺序处理即可。4. 客户端实现EventSource封装与降级策略4.1 标准EventSource的使用与限制浏览器原生EventSource用起来很简单const es new EventSource(/sse?clientIdabc); es.onmessage (e) { console.log(收到消息, e.data); }; es.addEventListener(price-update, (e) { const data JSON.parse(e.data); updatePrice(data); }); es.onerror (err) { console.error(SSE错误, err); };但原生EventSource有几个硬限制。不能自定义请求头比如想加Authorization token就不行只能通过URL参数传。不能发送POST请求只能GET。重连行为不可控浏览器自动重连但重连间隔由服务端的retry字段决定客户端无法干预。不支持二进制只能传文本。这些限制导致很多团队不用原生EventSource而是自己用fetch或XMLHttpRequest实现SSE解析。fetch支持流式读取可以自定义请求头但需要手动处理重连和事件解析。4.2 用长轮询模拟EventSource接口为了统一兼容性可以封装一个LongPollEventSource类对外暴露和EventSource一样的接口内部用长轮询循环实现。class LongPollEventSource { constructor(url, options {}) { this.url url; this.clientId options.clientId || generateId(); this.lastEventId null; this.listeners {}; this.running false; this.retryDelay options.retryDelay || 3000; } on(event, handler) { if (!this.listeners[event]) this.listeners[event] []; this.listeners[event].push(handler); } emit(event, data) { (this.listeners[event] || []).forEach(h h(data)); } async start() { this.running true; while (this.running) { try { const params new URLSearchParams({ clientId: this.clientId, lastEventId: this.lastEventId || }); const resp await fetch(${this.url}?${params}, { headers: { Accept: application/json } }); if (resp.status 204) { continue; // 超时无数据立即重试 } if (!resp.ok) { throw new Error(HTTP ${resp.status}); } const event await resp.json(); if (event.id) this.lastEventId event.id; this.emit(event.type || message, event); } catch (err) { this.emit(error, err); await sleep(this.retryDelay); } } } stop() { this.running false; } }这个封装的核心是循环lastEventId。每次请求带上上次收到的事件ID服务端据此判断是否有遗漏。收到204表示超时无数据立即发起下一次请求不等待。收到错误则按retryDelay退避重试。4.3 自动降级与连接健康检查实际部署时可以做一个自适应客户端先尝试SSE如果连接失败或超时未收到任何事件自动切换到长轮询。class AdaptiveEventSource { constructor(url, options) { this.url url; this.options options; this.impl null; this.sseTimeout null; } start() { if (typeof EventSource ! undefined) { this.trySse(); } else { this.useLongPoll(); } } trySse() { const es new EventSource(${this.url}/sse?clientId${this.options.clientId}); let received false; es.onmessage (e) { received true; clearTimeout(this.sseTimeout); this.emit(message, e); }; es.onerror () { es.close(); if (!received) { this.useLongPoll(); } }; // 5秒内没收到任何消息认为SSE不可用 this.sseTimeout setTimeout(() { if (!received) { es.close(); this.useLongPoll(); } }, 5000); this.impl es; } useLongPoll() { const lp new LongPollEventSource(${this.url}/poll, this.options); lp.start(); this.impl lp; } }健康检查的思路是SSE连接建立后服务端立即发送一个心跳事件如event: heartbeat客户端如果在5秒内收到心跳认为SSE通道正常否则降级。心跳还可以用于保活防止代理切断空闲连接。5. 性能调优与生产环境适配5.1 连接数、超时与心跳参数计算生产环境最怕连接数爆炸。假设单机要支撑1万个并发SSE连接每个连接占用一个文件描述符和一个内存缓冲区。Linux默认单进程fd上限是1024需要调整ulimit -n到65535以上。内存方面每个连接如果分配8KB缓冲区1万连接就是80MB可接受。长轮询的超时时间需要权衡。设30秒1万客户端平均每30秒发一次请求QPS约333。设60秒QPS约167。但超时越长服务端挂起连接越多内存压力越大。建议根据业务实时性要求选择行情推送用15-30秒通知类用60秒。心跳间隔建议15-30秒。太频繁浪费带宽太稀疏容易被中间设备判定为空闲连接而切断。心跳事件本身很小一个event: heartbeat\ndata: {}\n\n约30字节1万连接每30秒一次带宽约10KB/s可忽略。5.2 代理与网关的缓冲问题处理Nginx是SSE部署中最常见的坑。默认配置下Nginx会缓冲上游响应导致SSE消息攒批发送。解决方案location /sse { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ; proxy_buffering off; proxy_cache off; chunked_transfer_encoding off; proxy_read_timeout 3600s; }proxy_buffering off是核心关闭缓冲后Nginx收到数据立即转发。proxy_read_timeout要设大否则Nginx会在默认60秒后切断空闲连接。chunked_transfer_encoding off在某些版本下需要关闭避免分块编码问题。如果用的是云厂商的负载均衡要确认是否支持长连接和流式响应。部分LB有最大连接时长限制如5分钟到时间会强制断开。这时需要客户端自动重连并在重连后通过lastEventId补发遗漏消息。5.3 消息可靠性与断线续传SSE的Last-Event-ID机制是断线续传的基础。服务端为每个事件分配递增ID客户端重连时带上最后收到的ID服务端从EventStore中查询该ID之后的事件补发。EventStore的实现要考虑容量和过期。内存方案可以用ConcurrentHashMapString, RingBufferEvent每个客户端保留最近1000条事件超过则覆盖最旧的。Redis方案用ListLPUSH新事件LTRIM保留最近N条设置过期时间。注意如果客户端断线时间过长遗漏事件超过EventStore容量补发会不完整。这时应该让客户端做一次全量同步而不是依赖增量补发。可以在补发前检查ID是否在存储范围内不在则返回一个event: resync事件客户端收到后重新拉取全量数据。长轮询的可靠性类似每次请求带lastEventId服务端返回该ID之后的第一条事件。如果有多条客户端处理完后再发起下一次请求逐条拉取。这样保证不丢消息但吞吐量受限于往返延迟。6. 常见问题排查与避坑经验6.1 消息延迟与批量到达的排查现象SSE消息不是实时到达而是每隔几秒批量到达一批。排查思路首先检查Nginx的proxy_buffering是否关闭。其次检查服务端是否每次写入后flush。再次检查是否有中间层如CDN、WAF做了缓冲。可以用curl直接连服务端SSE端点观察消息到达时间curl -N -H Accept: text/event-stream http://localhost:8080/sse?clientIdtest如果curl实时输出说明服务端没问题问题在中间层。如果curl也是批量输出检查服务端代码是否flush。解决Nginx加proxy_buffering off和X-Accel-Buffering: no响应头。服务端每次write后调用flush。如果用了Spring的SseEmitter注意SseEmitter.send默认会flush但某些版本有缓冲需要手动调用。6.2 连接频繁断开的定位方法现象SSE连接每隔几十秒断开一次客户端不断重连。排查查看Nginx的proxy_read_timeout默认60秒。如果心跳间隔大于60秒Nginx会认为连接空闲而切断。解决是把心跳间隔设为小于proxy_read_timeout比如15秒。同时把proxy_read_timeout设大如3600秒。另一个原因是负载均衡的空闲超时。云LB通常有30-300秒的空闲超时心跳可以保活。如果LB有最大连接时长如5分钟到时间强制断开客户端重连即可但要在重连后补发遗漏消息。检查清单检查项推荐值说明Nginx proxy_read_timeout3600s避免空闲切断Nginx proxy_bufferingoff避免缓冲延迟心跳间隔15-30s小于所有中间层超时客户端重连延迟3-5s避免风暴服务端超时清理超时5s防止泄漏6.3 内存泄漏与连接泄漏的预防长轮询和SSE都涉及挂起连接如果清理不当会内存泄漏。常见泄漏点AsyncContext超时后没有从等待队列移除客户端断线后onError/onComplete没有清理EventStore无限增长预防措施在AsyncListener的onTimeout、onError、onComplete三个回调中都执行清理。等待队列用WeakReference或者定期扫描过期条目。EventStore设置容量上限和过期时间。用JMX或Micrometer暴露当前连接数、等待队列大小等指标设置告警阈值。实操心得我习惯在等待队列的每个条目上记录创建时间后台起一个定时任务每10秒扫描一次清理超过超时时间2倍的条目。这样即使某些异常路径没触发清理兜底任务也能保证不泄漏。6.4 浏览器连接数限制的应对HTTP/1.1下浏览器对同一域名最多6个并发连接。如果页面开了多个SSE连接比如多个模块各自订阅会占满连接导致其他请求排队。解决方案合并订阅用一个SSE连接订阅多个频道通过event type区分升级HTTP/2多路复用不受6连接限制用长轮询降级长轮询请求完成后连接释放不会长期占用合并订阅是最推荐的做法。客户端建立一个SSE连接服务端根据客户端的订阅列表推送不同event type的事件。客户端用addEventListener分别处理。const es new EventSource(/sse?clientIdabctopicsprice,notice,progress); es.addEventListener(price, e updatePrice(JSON.parse(e.data))); es.addEventListener(notice, e showNotice(JSON.parse(e.data))); es.addEventListener(progress, e updateProgress(JSON.parse(e.data)));服务端在EventBus分发时根据客户端的topics过滤只推送订阅的事件。这样单连接搞定所有推送需求。7. 方案选型对比与适用边界7.1 长轮询、SSE、WebSocket横向对比维度长轮询SSEWebSocket通信方向单向服务端到客户端单向服务端到客户端双向协议HTTPHTTP独立协议握手升级浏览器支持全部除IE外主流主流自动重连需自己实现原生支持需自己实现代理兼容性最好一般需关缓冲较差需升级支持连接开销每次请求重建一次连接持续一次连接持续实时性取决于超时高最高实现复杂度低低中高适用场景兼容性要求高、低频推送通知、日志、进度聊天、协作、游戏选型逻辑如果只需要服务端推客户端且环境可控优先SSE。如果环境复杂、代理多、浏览器杂用长轮询或混合方案。如果需要双向通信才上WebSocket。不要为了技术而技术WebSocket的连接管理和心跳保活成本比SSE高一个量级。7.2 什么场景该用混合方案混合方案适合以下情况用户群体浏览器版本跨度大部分不支持EventSource部署环境有不可控的代理或网关SSE可能被缓冲需要灰度发布先让一部分用户走SSE出问题自动降级对消息可靠性要求高需要lastEventId补发机制如果环境完全可控内网、现代浏览器、Nginx配置可改直接用SSE更简单。如果只是低频通知如每天几条长轮询足够没必要上SSE。混合方案的价值在于用一套客户端接口适配多种环境降低维护成本。7.3 扩展方向从单机到分布式单机方案跑通后扩展到分布式要考虑几个问题。连接粘性客户端的长轮询或SSE连接必须落到同一台服务端否则lastEventId补发会找不到事件。可以用一致性哈希或客户端绑定。事件广播业务事件产生后需要通知所有持有该客户端连接的服务端实例。用Redis Pub/Sub或消息队列广播。EventStore共享用Redis集中存储事件所有实例读写同一份。分布式下的心跳和超时管理更复杂建议用专门的连接网关层如基于Netty的自研网关统一管理连接业务服务通过内部RPC推送事件到网关。这样连接管理和业务逻辑解耦扩展性更好。最后分享一个小技巧在SSE的retry字段里设置一个合理的重连间隔比如retry: 3000这样浏览器自动重连时会等3秒避免服务端刚重启就被大量重连打垮。长轮询的客户端也要在错误后退避可以用指数退避第一次1秒第二次2秒最多30秒。这个细节在流量大的时候能救命。
1. 为什么要在长轮询和SSE之间做选择做实时消息推送的开发者几乎都绕不开一个经典问题服务端有数据更新时怎么第一时间告诉浏览器早期大家用短轮询前端每隔几秒发一次请求问“有没有新数据”实现简单但浪费严重——大部分请求都是空手而归服务端压力大实时性还差。后来有人用长轮询请求发出去后服务端不立刻返回而是hold住连接等有数据了再响应前端收到响应后马上再发一个请求如此循环。长轮询比短轮询省资源但每次数据到达后都要重新建立请求HTTP头反复传输连接开销依然存在。SSEServer-Sent Events是另一条路。它基于HTTP长连接服务端可以持续向客户端单向推送文本数据浏览器端用EventSource接口接收断线还能自动重连。SSE的定位很明确服务端到客户端的单向实时推送。它不像WebSocket那样支持双向通信但胜在协议简单、基于纯HTTP、浏览器原生支持、自带重连机制特别适合通知、日志流、进度更新、行情推送这类场景。这个项目标题“基于长轮询的SSE”核心思路是把长轮询的“hold住连接等数据”和SSE的“持续推送”结合起来。实际落地时很多团队并不是直接用标准SSE而是用长轮询的机制去模拟SSE的效果或者在SSE连接上叠加长轮询的兜底逻辑。为什么这么做因为标准SSE在某些代理、网关、老旧浏览器环境下会被缓冲或断开而长轮询的兼容性更好。两者结合既能拿到SSE的实时性又能用长轮询兜底保证消息不丢。这篇文章适合谁看如果你正在做实时消息推送、后台任务进度反馈、在线协作通知、监控告警面板或者你被WebSocket的复杂度和连接管理折磨过想找一个更轻量的方案那这篇内容可以直接抄作业。我会从设计思路、协议细节、代码实现、参数调优、问题排查几个维度把“基于长轮询的SSE”这套方案拆开讲透。2. 长轮询与SSE的核心机制拆解2.1 长轮询到底“长”在哪里长轮询的本质是服务端延迟响应。客户端发起一个普通HTTP请求服务端收到后不立即返回而是把请求挂起直到以下三种情况之一发生有新数据可推、等待超时、连接断开。一旦响应返回客户端立刻发起下一次长轮询请求形成“请求-挂起-响应-再请求”的循环。这里的关键参数是超时时间。设得太短退化成短轮询浪费请求设得太长服务端要维护大量挂起连接内存和文件描述符压力大。常见做法是30秒到60秒。以30秒为例如果这30秒内有数据服务端立刻返回如果没有30秒后返回一个空响应客户端再发起新一轮。这样平均每个客户端每30秒至少产生一次请求比短轮询每秒一次要省得多。长轮询的另一个重点是连接管理。服务端需要维护一个“等待队列”每个挂起的请求对应一个等待者。当数据产生时从队列中取出等待者写入响应并关闭连接。这里要处理并发安全、超时清理、客户端断线检测等问题。用Servlet 3.0的异步支持或者Netty这类NIO框架可以避免线程被阻塞。2.2 SSE的协议格式与浏览器行为SSE的协议非常简洁。服务端返回的Content-Type必须是text/event-stream响应体是一系列以\n\n分隔的事件块。每个事件块可以包含以下字段data:消息内容可以多行每行一个dataevent:自定义事件类型默认是messageid:事件ID用于断线重连时通过Last-Event-ID头告诉服务端从哪继续retry:重连等待毫秒数一个典型的事件块长这样id: 1001 event: price-update data: {symbol:ABC,price:123.45}浏览器端用new EventSource(/stream)建立连接然后监听message事件或自定义事件。EventSource会自动处理重连如果连接断开浏览器默认等待约3秒后重新发起请求并带上Last-Event-ID头。服务端可以根据这个ID决定从哪条消息开始补发。SSE的优点是单向、轻量、原生支持。缺点是浏览器对同一域名的HTTP/1.1连接数有限制通常6个如果开多个SSE连接会占满。HTTP/2下多路复用可以缓解但代理和网关对SSE的缓冲行为经常导致消息延迟。2.3 两者结合的设计动机标准SSE在理想环境下工作良好但实际生产环境有几个坑Nginx默认会缓冲响应导致消息不实时某些企业代理会切断长连接老旧浏览器不支持EventSource。长轮询的兼容性几乎无敌任何能发HTTP请求的环境都能用。“基于长轮询的SSE”通常有两种实现形态。第一种是SSE为主长轮询兜底优先用EventSource如果检测到不支持或连接异常降级为长轮询。第二种是用长轮询模拟SSE语义服务端提供长轮询接口客户端封装一个类似EventSource的对象内部用长轮询循环实现持续接收对外暴露onmessage等接口。第二种更常见于需要统一兼容性的场景。选择这种混合方案的理由很直接实时性、兼容性、实现成本三者平衡。WebSocket实时性最好但需要独立协议升级、连接管理复杂、部分代理不支持纯SSE简单但环境依赖强纯长轮询兼容好但每次重建连接有开销。混合方案在SSE可用时用SSE不可用时自动切换长轮询客户端代码几乎不用改。3. 服务端实现从连接挂起到事件推送3.1 长轮询接口的设计与超时控制先看长轮询接口。假设我们用Java Servlet 3.0的异步能力来实现。核心是一个AsyncContext把请求挂起然后注册到等待队列。WebServlet(urlPatterns /poll, asyncSupported true) public class LongPollServlet extends HttpServlet { private final WaitQueue waitQueue WaitQueue.getInstance(); private static final long TIMEOUT_MS 30_000L; protected void doGet(HttpServletRequest req, HttpServletResponse resp) { AsyncContext async req.startAsync(); async.setTimeout(TIMEOUT_MS); String clientId req.getParameter(clientId); String lastId req.getParameter(lastEventId); Waiter waiter new Waiter(clientId, lastId, async); waitQueue.add(waiter); async.addListener(new AsyncListener() { public void onTimeout(AsyncEvent event) { waitQueue.remove(waiter); writeResponse(async, 204, ); } public void onError(AsyncEvent event) { waitQueue.remove(waiter); } public void onComplete(AsyncEvent event) { waitQueue.remove(waiter); } }); } }这里有几个关键点。超时时间设为30秒通过async.setTimeout设置。超时后返回204 No Content客户端收到后立即发起下一次请求。等待队列用ConcurrentHashMap或LinkedBlockingQueue实现按clientId分组支持按lastEventId过滤。异步监听器负责在超时、出错、完成时清理等待者防止内存泄漏。当有新数据产生时业务代码调用waitQueue.notify(clientId, event)从队列中取出该客户端的所有等待者写入响应并完成异步上下文。写入格式可以是JSON客户端解析后处理。注意长轮询接口必须设置Cache-Control: no-cache和Connection: keep-alive避免中间层缓存空响应。同时要限制单客户端并发挂起数防止恶意请求占满连接。3.2 SSE端点的建立与事件格式化SSE端点用标准方式实现。设置响应头然后保持连接打开持续写入事件块。WebServlet(urlPatterns /sse, asyncSupported true) public class SseServlet extends HttpServlet { private final SseEmitterManager emitterManager SseEmitterManager.getInstance(); protected void doGet(HttpServletRequest req, HttpServletResponse resp) { resp.setContentType(text/event-stream); resp.setCharacterEncoding(UTF-8); resp.setHeader(Cache-Control, no-cache); resp.setHeader(Connection, keep-alive); resp.setHeader(X-Accel-Buffering, no); AsyncContext async req.startAsync(); async.setTimeout(0); // 不超时由客户端或服务端主动关闭 String clientId req.getParameter(clientId); String lastEventId req.getHeader(Last-Event-ID); SseClient client new SseClient(clientId, async, lastEventId); emitterManager.register(client); // 如果有Last-Event-ID补发遗漏事件 if (lastEventId ! null) { ListEvent missed eventStore.getAfter(clientId, lastEventId); for (Event e : missed) { client.send(e); } } } }事件格式化方法public void send(Event event) { StringBuilder sb new StringBuilder(); if (event.getId() ! null) { sb.append(id: ).append(event.getId()).append(\n); } if (event.getType() ! null) { sb.append(event: ).append(event.getType()).append(\n); } String[] lines event.getData().split(\n); for (String line : lines) { sb.append(data: ).append(line).append(\n); } sb.append(\n); async.getResponse().getWriter().write(sb.toString()); async.getResponse().getWriter().flush(); }X-Accel-Buffering: no这个头很关键它告诉Nginx不要缓冲SSE响应。没有这个头Nginx会攒够一定字节才发送导致消息延迟。另外每次写入后必须flush否则数据留在缓冲区。3.3 统一事件总线与消息分发长轮询和SSE两套接口需要共享同一个事件源。设计一个事件总线业务模块产生事件后发布到总线总线根据客户端订阅关系分发给SSE连接和长轮询等待者。public class EventBus { private final SseEmitterManager sseManager; private final WaitQueue waitQueue; private final EventStore eventStore; public void publish(String clientId, Event event) { eventStore.save(clientId, event); // 推给SSE连接 SseClient sseClient sseManager.get(clientId); if (sseClient ! null) { sseClient.send(event); } // 唤醒长轮询等待者 waitQueue.notify(clientId, event); } }EventStore用于持久化最近的事件支持按lastEventId补发。可以用内存环形缓冲区也可以用Redis List。内存方案简单但重启丢数据Redis方案可靠但多一次网络往返。根据业务对可靠性的要求选择。消息分发时要考虑顺序性。同一客户端的事件必须按产生顺序推送否则前端状态会乱。可以用单线程分发或者按clientId哈希到固定线程。SSE的写入是同步的天然有序长轮询每次响应一个事件客户端按顺序处理即可。4. 客户端实现EventSource封装与降级策略4.1 标准EventSource的使用与限制浏览器原生EventSource用起来很简单const es new EventSource(/sse?clientIdabc); es.onmessage (e) { console.log(收到消息, e.data); }; es.addEventListener(price-update, (e) { const data JSON.parse(e.data); updatePrice(data); }); es.onerror (err) { console.error(SSE错误, err); };但原生EventSource有几个硬限制。不能自定义请求头比如想加Authorization token就不行只能通过URL参数传。不能发送POST请求只能GET。重连行为不可控浏览器自动重连但重连间隔由服务端的retry字段决定客户端无法干预。不支持二进制只能传文本。这些限制导致很多团队不用原生EventSource而是自己用fetch或XMLHttpRequest实现SSE解析。fetch支持流式读取可以自定义请求头但需要手动处理重连和事件解析。4.2 用长轮询模拟EventSource接口为了统一兼容性可以封装一个LongPollEventSource类对外暴露和EventSource一样的接口内部用长轮询循环实现。class LongPollEventSource { constructor(url, options {}) { this.url url; this.clientId options.clientId || generateId(); this.lastEventId null; this.listeners {}; this.running false; this.retryDelay options.retryDelay || 3000; } on(event, handler) { if (!this.listeners[event]) this.listeners[event] []; this.listeners[event].push(handler); } emit(event, data) { (this.listeners[event] || []).forEach(h h(data)); } async start() { this.running true; while (this.running) { try { const params new URLSearchParams({ clientId: this.clientId, lastEventId: this.lastEventId || }); const resp await fetch(${this.url}?${params}, { headers: { Accept: application/json } }); if (resp.status 204) { continue; // 超时无数据立即重试 } if (!resp.ok) { throw new Error(HTTP ${resp.status}); } const event await resp.json(); if (event.id) this.lastEventId event.id; this.emit(event.type || message, event); } catch (err) { this.emit(error, err); await sleep(this.retryDelay); } } } stop() { this.running false; } }这个封装的核心是循环lastEventId。每次请求带上上次收到的事件ID服务端据此判断是否有遗漏。收到204表示超时无数据立即发起下一次请求不等待。收到错误则按retryDelay退避重试。4.3 自动降级与连接健康检查实际部署时可以做一个自适应客户端先尝试SSE如果连接失败或超时未收到任何事件自动切换到长轮询。class AdaptiveEventSource { constructor(url, options) { this.url url; this.options options; this.impl null; this.sseTimeout null; } start() { if (typeof EventSource ! undefined) { this.trySse(); } else { this.useLongPoll(); } } trySse() { const es new EventSource(${this.url}/sse?clientId${this.options.clientId}); let received false; es.onmessage (e) { received true; clearTimeout(this.sseTimeout); this.emit(message, e); }; es.onerror () { es.close(); if (!received) { this.useLongPoll(); } }; // 5秒内没收到任何消息认为SSE不可用 this.sseTimeout setTimeout(() { if (!received) { es.close(); this.useLongPoll(); } }, 5000); this.impl es; } useLongPoll() { const lp new LongPollEventSource(${this.url}/poll, this.options); lp.start(); this.impl lp; } }健康检查的思路是SSE连接建立后服务端立即发送一个心跳事件如event: heartbeat客户端如果在5秒内收到心跳认为SSE通道正常否则降级。心跳还可以用于保活防止代理切断空闲连接。5. 性能调优与生产环境适配5.1 连接数、超时与心跳参数计算生产环境最怕连接数爆炸。假设单机要支撑1万个并发SSE连接每个连接占用一个文件描述符和一个内存缓冲区。Linux默认单进程fd上限是1024需要调整ulimit -n到65535以上。内存方面每个连接如果分配8KB缓冲区1万连接就是80MB可接受。长轮询的超时时间需要权衡。设30秒1万客户端平均每30秒发一次请求QPS约333。设60秒QPS约167。但超时越长服务端挂起连接越多内存压力越大。建议根据业务实时性要求选择行情推送用15-30秒通知类用60秒。心跳间隔建议15-30秒。太频繁浪费带宽太稀疏容易被中间设备判定为空闲连接而切断。心跳事件本身很小一个event: heartbeat\ndata: {}\n\n约30字节1万连接每30秒一次带宽约10KB/s可忽略。5.2 代理与网关的缓冲问题处理Nginx是SSE部署中最常见的坑。默认配置下Nginx会缓冲上游响应导致SSE消息攒批发送。解决方案location /sse { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ; proxy_buffering off; proxy_cache off; chunked_transfer_encoding off; proxy_read_timeout 3600s; }proxy_buffering off是核心关闭缓冲后Nginx收到数据立即转发。proxy_read_timeout要设大否则Nginx会在默认60秒后切断空闲连接。chunked_transfer_encoding off在某些版本下需要关闭避免分块编码问题。如果用的是云厂商的负载均衡要确认是否支持长连接和流式响应。部分LB有最大连接时长限制如5分钟到时间会强制断开。这时需要客户端自动重连并在重连后通过lastEventId补发遗漏消息。5.3 消息可靠性与断线续传SSE的Last-Event-ID机制是断线续传的基础。服务端为每个事件分配递增ID客户端重连时带上最后收到的ID服务端从EventStore中查询该ID之后的事件补发。EventStore的实现要考虑容量和过期。内存方案可以用ConcurrentHashMapString, RingBufferEvent每个客户端保留最近1000条事件超过则覆盖最旧的。Redis方案用ListLPUSH新事件LTRIM保留最近N条设置过期时间。注意如果客户端断线时间过长遗漏事件超过EventStore容量补发会不完整。这时应该让客户端做一次全量同步而不是依赖增量补发。可以在补发前检查ID是否在存储范围内不在则返回一个event: resync事件客户端收到后重新拉取全量数据。长轮询的可靠性类似每次请求带lastEventId服务端返回该ID之后的第一条事件。如果有多条客户端处理完后再发起下一次请求逐条拉取。这样保证不丢消息但吞吐量受限于往返延迟。6. 常见问题排查与避坑经验6.1 消息延迟与批量到达的排查现象SSE消息不是实时到达而是每隔几秒批量到达一批。排查思路首先检查Nginx的proxy_buffering是否关闭。其次检查服务端是否每次写入后flush。再次检查是否有中间层如CDN、WAF做了缓冲。可以用curl直接连服务端SSE端点观察消息到达时间curl -N -H Accept: text/event-stream http://localhost:8080/sse?clientIdtest如果curl实时输出说明服务端没问题问题在中间层。如果curl也是批量输出检查服务端代码是否flush。解决Nginx加proxy_buffering off和X-Accel-Buffering: no响应头。服务端每次write后调用flush。如果用了Spring的SseEmitter注意SseEmitter.send默认会flush但某些版本有缓冲需要手动调用。6.2 连接频繁断开的定位方法现象SSE连接每隔几十秒断开一次客户端不断重连。排查查看Nginx的proxy_read_timeout默认60秒。如果心跳间隔大于60秒Nginx会认为连接空闲而切断。解决是把心跳间隔设为小于proxy_read_timeout比如15秒。同时把proxy_read_timeout设大如3600秒。另一个原因是负载均衡的空闲超时。云LB通常有30-300秒的空闲超时心跳可以保活。如果LB有最大连接时长如5分钟到时间强制断开客户端重连即可但要在重连后补发遗漏消息。检查清单检查项推荐值说明Nginx proxy_read_timeout3600s避免空闲切断Nginx proxy_bufferingoff避免缓冲延迟心跳间隔15-30s小于所有中间层超时客户端重连延迟3-5s避免风暴服务端超时清理超时5s防止泄漏6.3 内存泄漏与连接泄漏的预防长轮询和SSE都涉及挂起连接如果清理不当会内存泄漏。常见泄漏点AsyncContext超时后没有从等待队列移除客户端断线后onError/onComplete没有清理EventStore无限增长预防措施在AsyncListener的onTimeout、onError、onComplete三个回调中都执行清理。等待队列用WeakReference或者定期扫描过期条目。EventStore设置容量上限和过期时间。用JMX或Micrometer暴露当前连接数、等待队列大小等指标设置告警阈值。实操心得我习惯在等待队列的每个条目上记录创建时间后台起一个定时任务每10秒扫描一次清理超过超时时间2倍的条目。这样即使某些异常路径没触发清理兜底任务也能保证不泄漏。6.4 浏览器连接数限制的应对HTTP/1.1下浏览器对同一域名最多6个并发连接。如果页面开了多个SSE连接比如多个模块各自订阅会占满连接导致其他请求排队。解决方案合并订阅用一个SSE连接订阅多个频道通过event type区分升级HTTP/2多路复用不受6连接限制用长轮询降级长轮询请求完成后连接释放不会长期占用合并订阅是最推荐的做法。客户端建立一个SSE连接服务端根据客户端的订阅列表推送不同event type的事件。客户端用addEventListener分别处理。const es new EventSource(/sse?clientIdabctopicsprice,notice,progress); es.addEventListener(price, e updatePrice(JSON.parse(e.data))); es.addEventListener(notice, e showNotice(JSON.parse(e.data))); es.addEventListener(progress, e updateProgress(JSON.parse(e.data)));服务端在EventBus分发时根据客户端的topics过滤只推送订阅的事件。这样单连接搞定所有推送需求。7. 方案选型对比与适用边界7.1 长轮询、SSE、WebSocket横向对比维度长轮询SSEWebSocket通信方向单向服务端到客户端单向服务端到客户端双向协议HTTPHTTP独立协议握手升级浏览器支持全部除IE外主流主流自动重连需自己实现原生支持需自己实现代理兼容性最好一般需关缓冲较差需升级支持连接开销每次请求重建一次连接持续一次连接持续实时性取决于超时高最高实现复杂度低低中高适用场景兼容性要求高、低频推送通知、日志、进度聊天、协作、游戏选型逻辑如果只需要服务端推客户端且环境可控优先SSE。如果环境复杂、代理多、浏览器杂用长轮询或混合方案。如果需要双向通信才上WebSocket。不要为了技术而技术WebSocket的连接管理和心跳保活成本比SSE高一个量级。7.2 什么场景该用混合方案混合方案适合以下情况用户群体浏览器版本跨度大部分不支持EventSource部署环境有不可控的代理或网关SSE可能被缓冲需要灰度发布先让一部分用户走SSE出问题自动降级对消息可靠性要求高需要lastEventId补发机制如果环境完全可控内网、现代浏览器、Nginx配置可改直接用SSE更简单。如果只是低频通知如每天几条长轮询足够没必要上SSE。混合方案的价值在于用一套客户端接口适配多种环境降低维护成本。7.3 扩展方向从单机到分布式单机方案跑通后扩展到分布式要考虑几个问题。连接粘性客户端的长轮询或SSE连接必须落到同一台服务端否则lastEventId补发会找不到事件。可以用一致性哈希或客户端绑定。事件广播业务事件产生后需要通知所有持有该客户端连接的服务端实例。用Redis Pub/Sub或消息队列广播。EventStore共享用Redis集中存储事件所有实例读写同一份。分布式下的心跳和超时管理更复杂建议用专门的连接网关层如基于Netty的自研网关统一管理连接业务服务通过内部RPC推送事件到网关。这样连接管理和业务逻辑解耦扩展性更好。最后分享一个小技巧在SSE的retry字段里设置一个合理的重连间隔比如retry: 3000这样浏览器自动重连时会等3秒避免服务端刚重启就被大量重连打垮。长轮询的客户端也要在错误后退避可以用指数退避第一次1秒第二次2秒最多30秒。这个细节在流量大的时候能救命。
