SSE vs WebSocket vs HTTP轮询：直播间实时评论系统架构设计详解

现在，抖音、B站、快手等大平台都提供直播功能。为了提高用户活跃度，直播间的实时评论发布与接收功能是核心互动环节之一，其效果如下图所示：

那么，当用户进入直播间后，发布评论和接收实时评论的功能是如何设计和实现的呢？下面我们来探讨几种常见的技术方案。

1. HTTP轮询实现方案

HTTP轮询是一种典型的 Pull 模型实现方式。其原理是客户端（如网页或App）以固定的时间间隔（例如每秒一次）向服务器发起请求，主动“拉取”最新的评论数据，并在直播间界面展示。

然而，HTTP轮询方案存在明显的缺陷。它难以实现低延迟的实时评论接收。为了提升实时性，如果缩短轮询间隔、增加请求频率，对于那些评论稀少的直播间而言，将会产生大量无效的HTTP请求，造成服务器和网络资源的严重浪费。

2. WebSocket实现方案

WebSocket 在客户端和服务端之间建立了一条双向通信的全双工通道。一旦连接成功建立并保持，双方即可随时相互发送数据。

设想一个场景：用户A和用户B都进入了直播间001，并成功与服务器建立了WebSocket连接。当用户A发表一条新评论时，评论数据被发送到服务器。服务器随即通过已建立的WebSocket连接，将这条新评论实时“推送”给用户B。同时，服务器通常会发送一条消息到消息队列（如Kafka或RabbitMQ），由下游服务异步完成评论数据的持久化存储。

相比HTTP轮询，WebSocket方案效率更高。它彻底消除了轮询带来的延迟问题，服务器能在新评论产生的瞬间就将其推送给所有在线的客户端。

但在实际的直播业务中，大多数用户是“沉默的观看者”，发言较少，读取评论较多。为所有用户维持一个双向的WebSocket连接，意义不大，反而会带来额外的连接维护开销。因此，在实时评论这种以服务器向客户端单向推送为主的场景下，一般不推荐首选WebSocket方案。

3. SSE (Server-Sent Events) 实现方案

SSE 可以看作是 WebSocket 的一种轻量级替代方案。它基于标准的 HTTP 协议，是一个从服务器到客户端的单向通道，专门用于服务器向客户端推送消息。这种特性使其非常适合实时评论推送这类场景。

在用户发言少、读评论多的直播间环境下，SSE 是一个更优的选择。同样以用户A和用户B为例，当用户A发表评论后，服务器通过已建立的 SSE 连接，将新评论推送给用户B。这种方式避免维护双向通道，显著减少了连接开销。

集群模式下的挑战

随着用户大量涌入某个热门直播间，单机服务必然无法承受压力，必须采用集群模式来提供高可用和高性能的服务。部署架构如下图所示：

但在集群模式下，会出现一个新的问题：某些用户可能无法接收到最新评论。例如：

• 用户A和用户B在直播间001，他们的SSE连接建立在服务器001上。
• 用户C也在直播间001，但他的SSE连接建立在服务器002上。

如果用户C发表了一条评论，该请求被发送到服务器002处理。那么，服务器001上的用户A和B将无法实时收到这条评论，因为服务器002并不知道服务器001上连接了哪些客户端，反之亦然。这就导致了评论推送在不同服务器实例间无法同步。

4. 基于SSE的升级实现方案

为了解决上述集群间的数据同步问题，我们需要设计一个更健壮的架构。核心思路是将连接维护服务（专门管理SSE连接）和评论业务服务（处理评论的发表与查询）进行解耦。具体设计如下图所示：

1. 连接建立：用户A和用户B与 SSE 服务集群成功建立连接。
2. 评论发布：用户B发送一条评论到直播间001，请求被负载均衡到评论服务集群的某个实例。
3. 消息分发：评论服务实例需要完成两件事：
   • 将评论数据发送到一个落库MQ，由消费者异步持久化到数据库。
   • 同时，发送一条推送MQ消息，其内容包含了直播间ID和这条新评论数据。
4. 集群广播：整个SSE服务集群都订阅了这个推送MQ。任何一个SSE服务实例消费到这条消息后，都会根据消息中的直播间ID，查找本机维护的所有该直播间的SSE连接，并将评论数据推送出去。

通过引入消息队列作为中间件，实现了评论数据的跨服务器广播，从而构建了一个高可用的实时评论系统。

当然，这个升级方案也并非完美。随着直播间评论量的激增，MQ中的消息会急剧增多，可能带来消息处理延迟，影响推送的实时性。这需要通过优化MQ性能、增加消费者数量或采用更高效的消息路由策略来进一步解决。希望本文分享的几种架构思路，能对你在设计实时系统时有所启发。更多关于高并发和分布式系统的讨论，欢迎来到云栈社区交流。