浅谈直播间实时评论功能的背后技术-优快云博客

本文链接：https://blog.youkuaiyun.com/static_coder/article/details/147441429

平台奖励创作，可能会升级VIP文章，可以移步我的公众号：【编程朝花夕拾】，且可获取首发内容。

01 引言

随着短视频的火爆，人人直播的时代已经到来，更是降低了直播的门槛。硬是从老牌的直播平台斗鱼、虎牙等分走了大部分流量。

直播间少不了博主和粉丝的互动，实时共享粉丝的留言也成了必不可少的功能。B站的弹幕也是类似的功能。

那么直播间的评论功能是怎么实现的呢？是不是就是简单的一发，只有将用户发送的评论展示出来就好了。

02 拆解功能的背后

「低延迟」是直播间的实时评论其中最重要的因素之一，意味着用户发出的信息，直播间的所有人立马能够看到此消息。必须控制在大约300ms内触达所有在线观众。

「高并发」是直播间最具有挑战的难点之一，直播间的人数关系着真个系统的稳定性。而直播间的人数从来都是不定的，受欢迎的主播直播间成千上万人，这个很难去评估。例如每次娱乐圈的大新闻，大量吃瓜群众涌入导致的新浪微博的崩溃。

「容错能力」是当代网络必须要面临的挑战，如果出现网络抖动、流量突增、服务器宕机等异常场景，如何保证系统的稳定运行。

「敏感词」是对公共环境、文明用语的保证。很多直播间如抖音、快手、微信短视频都是没有门槛的，如果没有敏感词的过滤，就可能演变成不良信息或语言的传播。

「通讯」是用户之间交流的桥梁。双端通信还是单端通信，使用的协议等直接影响到通讯的效果。

这种场景除了直播间，还有我们经常使用的微信、QQ的群聊功能。

03 架构分层

客户端用户发起消息，服务端接收层先接收到消息后转发给业务处理层。业务层进行敏感词过滤，根据规则是否禁言当前客户端。

将处理好的消息，交给推送的消息的模块，然后由其统一分发给每一个客户端。这就实现了一个人发送消息，直播间所有的人都能看到了。

至于客户端发送的消息需不需要收集，取决于业务需要。正常来说没有要收集，也就不用存储了。就像微信聊天，服务器端就不会存储用户的聊天内容，要不然内部员工就有可能看到你的所有聊天记录。

04 技术选型

技术的选型每一个公司或者个人都可能存在差异，需要结合公司或个人目前现有的资源、技术栈。技术都是服务于业务的，每一种的业务功能的实现，不同的技术实现的过程都是不相同的。

4.1 服务框架

服务框架是代码编写的脚手架，可以采用目前流程的Spring家族的SpringBoot + Spring Cloud，也可以选择Springboot + Spring Cloud Alibaba。当然Spring Cloud Alibaba 已经捐献给Spring，也属于Spring 生态的一部分。

微服务即可以选择Spring的 OpenFeign也可以选择熟悉的阿里系Dubbo，当然现在已经捐献给apache基金会。笔者建议，如果使用的Springboot版本过低（1.x）或对OpenFeign不熟悉的话，直接选择Dubbo。因为OpenFeign使用的默认协议是http协议，需要每次调用都会经过三次握手、四次挥手。这样的效率在不调优的情况下，远远没有Dubbo的效率高，同等配置下Dubbo更能应对高并发场景。

Dubbo在Spring Cloud Alibaba 2021.0.1.0 及以后得版本就把Dubbo踢出框架，不在强依赖Dubbo。使用的时候需要自行引入。

不要问我怎么知道的？都是血泪教训。经历了Dubbo服务到Spring Cloud OpenFeign的改造，又经历了OpenFeign到Dubbo的回退。

4.2 传输的协议

常用的请求协议就是Http协议，应用十分广泛。直播间的通讯应该使用什么协议呢？

首先要明确的，直播间发送信息请求的链接不应该是短连接。长连接才能保持即时收到服务端推送的消息。WebSocket协议，支持全双工通信，基于Netty 框架，采用NIO模型，高效处理数据，天然的支持直播间的这种场景。这大概也是各种聊天工具都会使用的一种协议吧。

那Http协议能否支持呢？那就需要打破Http短连接的思维定式。SSE(Server-Sent Events)是基于Http请求的服务端推给客户端的单项服务器推送技术，这项技术也被广泛应用在大模型tokens的返回。而客户端向服务端的数据推送可以借助普通的请求去弥补。所以SSE也是可以支持的。

SSE是Spring 自带的一项功能，使用起来更加流程，无需引入其他的三方库。直播间并不是所有人都会发送消息，大多数人都是吃瓜群众，也就降低了双向通讯的压力，更能满足SSE的使用，而且SSE的单项推送也会节省资源的开销。