面向海量用户的实时数据流推送：Server Send Events等技术选型咨询

Great question—let’s break down each option and zero in on the best fit for your use case: user subscriptions to real-time data streams with a focus on supporting massive concurrent users.

Let’s Start with the Outdated Option: Comet #

Comet is an umbrella term for old-school techniques like long polling, iframe streaming, and XHR streaming. While it works for basic real-time needs, it’s not recommended for massive users:

• It’s inefficient: Long polling relies on repeated HTTP requests (even when there’s no data), wasting server resources.
• Connection management is a headache: Each "stream" ties up a dedicated HTTP connection, which quickly hits limits with thousands of users.
• It’s been largely replaced by modern standards like SSE and WebSockets, so you’d be building on a legacy approach with limited tooling support.

Server-Sent Events (SSE): Perfect for One-Way Push #

SSE is a standard HTTP-based protocol designed explicitly for server-to-client real-time streaming. This is a strong candidate for your use case, and here’s why:

• One-way focus matches your needs: Your users are subscribing to receive data, not sending frequent updates back to the server. SSE is built for this exact scenario.
• Lightweight & easy to implement: No fancy protocol handshakes—just a standard HTTP response with text/event-stream content type. Most server frameworks (Node.js, Python, Java) have simple SSE libraries, and browsers handle the connection/auto-reconnect natively.
• Built-in reliability: SSE automatically attempts to reconnect if the connection drops, and you can send last-event-id to resume streams from where the user left off.

The only catch with SSE in HTTP/1.1 is the per-domain connection limit (usually 6), but that’s solved by pairing it with HTTP/2.

WebSockets: Overkill for One-Way Push #

WebSockets enable full-duplex (bidirectional) communication, which is great for use cases like chat apps, real-time collaboration, or multiplayer games. But for your subscription-focused scenario:

• It’s overengineered: You don’t need the ability to send data from client to server in real time (unless you plan to add features like instant subscription changes later). The extra overhead of the WebSocket handshake and persistent full-duplex connections uses more server resources than SSE.
• Higher complexity: WebSockets require dedicated server support (you can’t just use a standard HTTP server) and more work to handle connection management, reconnections, and message framing at scale.

If you’re certain you’ll need bidirectional communication down the line, WebSockets are viable—but they’re not the most efficient choice for your current use case.

HTTP/2: Not a Standalone Solution, but a Game-Changer for Scale #

HTTP/2 isn’t a real-time streaming protocol itself—it’s an upgrade to the HTTP protocol that adds features like multiplexing, server push, and header compression. Here’s how it fits:

• Pair it with SSE to solve scale issues: HTTP/2 allows multiple SSE streams to share a single TCP connection, eliminating the HTTP/1.1 connection limit. This drastically reduces server resource usage and lets you support far more concurrent users.
• Note on HTTP/2 server push: Don’t confuse this with your data stream needs—HTTP/2 server push is for pre-sending static resources (like CSS or JS) to clients, not for real-time data subscriptions.

The Optimal Choice for Massive Users #

If your core use case is one-way real-time data subscriptions (users receive updates, no need to send data back in real time), the clear winner is:

SSE + HTTP/2 #

Here’s why it’s best for scale:

1. Low resource overhead: HTTP/2 multiplexing means fewer TCP connections, reducing CPU and memory load on your servers.
2. Standardized & maintainable: Built on HTTP, so you can leverage existing HTTP infrastructure (load balancers, caching layers) without special configuration.
3. Scalable with async frameworks: Pair SSE with an async server (like Node.js with Express, Python’s FastAPI, or Java’s Spring WebFlux) to handle tens of thousands of concurrent connections efficiently.
4. Easy to scale horizontally: Use a message broker (like Redis Pub/Sub or Kafka) to distribute data across multiple server instances, so no single server is overwhelmed by pushing to thousands of users.

If you anticipate needing bidirectional communication in the future, you can start with SSE and migrate to WebSockets later, or use a hybrid approach—but for now, SSE + HTTP/2 is the most efficient, cost-effective choice for massive concurrent subscribers.

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