直播系统聊天技术(七)：直播间海量聊天消息的架构设计难点实践

1、引言

在视频直播场景中，弹幕交互、与主播的聊天、各种业务指令等等，组成了普通用户与主播之间的互动方式。

从技术的角度来看，这些实时互动手段，底层逻辑都是实时聊天消息或指令的分发，技术架构类比于IM应用的话，那就相当于IM聊天室功能。

本文将主要从高可用、弹性扩缩容、用户管理、消息分发、客户端优化等角度，分享直播间海量聊天消息的架构设计技术难点的实践经验。

2直播间的主要功能和技术特征

如今的视频直播间早已不单纯是视频流媒体技术问题，它还包含了用户可感知的多类型消息发送和管理、用户管理等任务。在万物皆可直播的当下，超大型直播场景屡见不鲜，甚至出现了人数无上限的场景，面对如此海量实时消息和指令的并发挑战，带来的技术难度已非常规手段所能解决。

我们先来归纳一下如今的典型视频直播间，相较于传统直播间所包含的主要功能特征、技术特征等。

丰富的消息类型和进阶功能：
 

• 1）可发送文字、语音、图片等传统聊天功能；
• 2）可实现点赞、礼物等非传统聊天功能的消息类型；
• 3）可管理内容安全，包括敏感词设置，聊天内容反垃圾处理等。

聊天管理功能：
 

• 1）用户管理：包括创建、加入、销毁、禁言、查询、封禁（踢人）等；
• 2）用户白名单：白名单用户处于被保护状态不会被自动踢出，且发送消息优先级别最高；
• 3）消息管理：包括消息优先级、消息分发控制等；
• 4）实时统计及消息路由等能力。

人数上限和行为特征：
 

• 1）人数没有上限：一些大型直播场景，如春晚、国庆大阅兵等，直播间累计观看动辄上千万人次，同时观看人数也可达数百万；
• 2）用户进退行为：用户进出直播间非常频繁，高热度直播间的人员进出秒并发可能上万，这对服务支撑用户上下线以及用户管理的能力提出了非常大的挑战。

海量消息并发：
 

• 1）消息并发量大：直播聊天室人数没有明显上限，带来了海量并发消息的问题（一个百万人数的聊天室，消息的上行已是巨量，消息分发量更是几何级上升）；
• 2）消息实时性高：如果服务器只做消息的消峰处理，峰值消息的堆积会造成整体消息延时增大。

针对上述第 2） 点，延时的累积效应会导致消息与直播视频流在时间线上产生偏差，进而影响用户观看直播时互动的实时性。所以，服务器的海量消息快速分发能力十分重要。

3直播间聊天室的架构设计

高可用系统需要支持服务故障自动转移、服务精准熔断降级、服务治理、服务限流、服务可回滚、服务自动扩容 / 缩容等能力。

以服务高可用为目标的直播间聊天室系统架构如下：

 如上图所示，系统架构主要分三层：
 

• 1）连接层：主要管理服务跟客户端的长链接；
• 2）存储层：当前使用的是 Redis，作为二级缓存，主要存储聊天室的信息（比如人员列表、黑白名单、封禁列表等，服务更新或重启时，可以从 Redis 中加载出聊天室的备份信息）；
• 3）业务层：这是整个聊天室的核心，为了实现跨机房容灾，将服务部署在多个可用区，并根据能力和职责，将其分为聊天室服务和消息服务。

聊天室服务和消息服务的具体职责：
 

• 1）聊天室服务：主要负责处理管理类请求，比如聊天室人员的进出、封禁 / 禁言、上行消息处理审核等；
• 2）消息服务：主要缓存本节点需要处理的用户信息以及消息队列信息，并负责聊天室消息的分发。

在海量用户高并发场景下，消息分发能力将决定着系统的性能。以一个百万级用户量的直播间聊天室为例，一条上行消息对应的是百万倍的分发。这种情况下，海量消息的分发，依靠单台服务器是无法实现的。

我们的优化思路是：将一个聊天室的人员分拆到不同的消息服务上，在聊天室服务收到消息后向消息服务扩散，再由消息服务分发给用户。

以百万在线的直播间聊天室为例：假设聊天室消息服务共 200 台，那平均每台消息服务管理 5000 人左右，每台消息服务在分发消息时只需要给落在本台服务器上的用户分发即可。

服务落点的选择逻辑：
 

• 1）在聊天室服务中：聊天室的上行信令是依据聊天室 ID 使用一致性哈希算法来选择节点的；
• 2）在消息服务中：依据用户 ID 使用一致性哈希算法来决定用户具体落在哪个消息服务。

一致性哈希选择的落点相对固定，可以将聊天室的行为汇聚到一个节点上，极大提升服务的缓存命中率。