浅析直播间海量聊天消息的架构设计难点

Posted 2022-06-17 wecloud1314

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

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

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

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

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

    1）可发送文字、语音、图片等传统聊天功能；

    2）可实现点赞、礼物等非传统聊天功能的消息类型；

    3）可管理内容安全，包括敏感词设置，聊天内容反垃圾处理等。

聊天管理功能：

    1）用户管理：包括创建、加入、销毁、禁言、查询、封禁（踢人）等；

    2）用户白名单：白名单用户处于被保护状态不会被自动踢出，且发送消息优先级别最高；

    3）消息管理：包括消息优先级、消息分发控制等；

    4）实时统计及消息路由等能力。

人数上限和行为特征：

    1）人数没有上限：一些大型直播场景，如春晚、国庆大阅兵等，直播间累计观看动辄上千万人次，同时观看人数也可达数百万；

    2）用户进退行为：用户进出直播间非常频繁，高热度直播间的人员进出秒并发可能上万，这对服务支撑用户上下线以及用户管理的能力提出了非常大的挑战。

海量消息并发：

    1）消息并发量大：直播聊天室人数没有明显上限，带来了海量并发消息的问题（一个百万人数的聊天室，消息的上行已是巨量，消息分发量更是几何级上升）；

    2）消息实时性高：如果服务器只做消息的消峰处理，峰值消息的堆积会造成整体消息延时增大。

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

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

系统架构主要分三层：

    1）连接层：主要管理服务跟客户端的长链接；

    2）存储层：当前使用的是 Redis，作为二级缓存，主要存储聊天室的信息（比如人员列表、黑白名单、封禁列表等，服务更新或重启时，可以从 Redis 中加载出聊天室的备份信息）；

    3）业务层：这是整个聊天室的核心，为了实现跨机房容灾，将服务部署在多个可用区，并根据能力和职责，将其分为聊天室服务和消息服务。

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

    1）聊天室服务：主要负责处理管理类请求，比如聊天室人员的进出、封禁 / 禁言、上行消息处理审核等；

    2）消息服务：主要缓存本节点需要处理的用户信息以及消息队列信息，并负责聊天室消息的分发。

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

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

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

服务落点的选择逻辑：

    1）在聊天室服务中：聊天室的上行信令是依据聊天室 ID 使用一致性哈希算法来选择节点的；

    2）在消息服务中：依据用户 ID 使用一致性哈希算法来决定用户具体落在哪个消息服务。

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

聊天室人员进出、黑 / 白名单设置以及消息发送时的判断等处理直接访问内存即可，无须每次都访问第三方缓存，从而提高了聊天室的响应速度和分发速度。

随着直播这种形式被越来越多人接受，直播间聊天室面对人数激增致使服务器压力逐步增大的情况越来越多。所以，在服务压力逐步增大 / 减少的过程中能否进行平滑的扩 / 缩容非常重要。

在服务的自动扩缩容方面，业内提供的方案大体一致：即通过压力测试了解单台服务器的瓶颈点 → 通过对业务数据的监控来判断是否需要进行扩缩 → 触发设定的条件后报警并自动进行扩缩容。

鉴于直播间聊天室的强业务性，具体执行中应该保证在扩缩容中整体聊天室业务不受影响。

聊天室服务在进行扩缩容时，我们通过 Redis 来加载成员列表、封禁 / 黑白名单等信息。

需要注意的是：在聊天室进行自动销毁时，需先判断当前聊天室是否应该是本节点的。如果不是，跳过销毁逻辑，避免 Redis 中的数据因为销毁逻辑而丢失。即时通讯聊天软件app开发可以咨询蔚可云。

消息服务在进行扩缩容时，大部分成员需要按照一致性哈希的原则路由到新的消息服务节点上。这个过程会打破当前的人员平衡，并做一次整体的人员转移。

1）在扩容时：我们根据聊天室的活跃程度逐步转移人员。

2）在有消息时：[消息服务会遍历缓存在本节点上的所有用户进行消息的通知拉取，在此过程中判断此用户是否属于这台节点（如果不是，将此用户同步加入到属于他的节点）。

3）在拉消息时：用户在拉取消息时，如果本机缓存列表中没有该用户，消息服务会向聊天室服务发送请求确认此用户是否在聊天室中（如果在则同步加入到消息服务，不在则直接丢掉）。

4）在缩容时：消息服务会从公共 Redis 获得全部成员，并根据落点计算将本节点用户筛选出来并放入用户管理列表中。