im即时通讯开发：百万人的直播实时聊天消息分发技术

随着直播类应用的普及，尤其直播带货概念的风靡，大用户量的直播间场景已然常态化。

大用户量直播间中的实时互动是非常频繁的，具体体现在技术上就是各种用户聊天、弹幕、礼物、点赞、禁言、系统通知等实时消息

如此大量的实时消息，在分发时如何处理才能不至于把服务端搞垮，而到了客户端时也不至于让APP出现疯狂刷屏和卡顿（不至于影响用户体验），这显然需要特殊的技术手段和实现策略才能应对。

其实，直播间中的实时消息分发，在技术上是跟传统的在线聊天室这种概念是一样的，只是传统互联网时代，聊天室同时在线的用户量不会这么大而已，虽然量级不同，但技术模型是完全可以套用的。

我们以一个百万人观看的直播间为例进行分析，看看需要面临哪些技术挑战。

1）在直播中会有一波一波的消息高峰，比如直播中的“刷屏”消息，即大量用户在同一时段发送的海量实时消息，一般情况下此类“刷屏”消息的消息内容基本相同。如果将所有消息全部展示在客户端，则客户端很可能出现卡顿、消息延迟等问题，严重影响用户体验。

2）海量消息的情况下，如果服务端每条消息都长期存储将导致服务缓存使用量激增，使得内存、存储成为性能瓶颈。

3）在另外一些场景下，比如直播间的房间管理员进行操作后的通知消息或者系统通知，一般情况下这类消息是较为重要的，如何优先保障它的到达率。即时通讯聊天软件开发可以咨询蔚可云。

基于这些挑战，我们的服务需要做一个基于业务场景的优化来应对。

下面将针对主要服务进行简要说明。

1）直播间服务：

主要作用是：缓存直播间的基本信息。包括用户列表、禁言/封禁关系、白名单用户等。

2）消息服务：

主要作用是：缓存本节点需要处理的用户关系信息、消息队列信息等。

具体说是以下两个主要事情。

直播间用户关系同步：

a）成员主动加入退出时：直播间服务同步至==> 消息服务；

b）分发消息发现用户已离线时：消息服务同步至==> 直播间服务。

发送消息：

a）直播间服务经过必要校验通过后将消息广播至消息服务；

b）直播间服务不缓存消息内容。

3）Zk（就是Zookeeper啦）：

主要作用就是：将各服务实例均注册到 Zk，数据用于服务间流转时的落点计算。

具体就是：

a）直播间服务：按照直播间 ID 落点；

b）消息服务：按照用户 ID 落点。

4）Redis：

主要作为二级缓存，以及服务更新（重启）时内存数据的备份。

我们的消息分发流程主要是以下几步：

1）用户 A 在直播间中发送一条消息，首先由直播间服务处理；

2）直播间服务将消息同步到各消息服务节点；

3）消息服务向本节点缓存的所有成员下发通知拉取；

4）如上图中的“消息服务-1”，将向用户 B 下发通知。

另外，因为消息量过大，我们在在分发的过程中，是具有通知合并机制的，通知合并机制主要提现在上述步骤3中。

上述步骤3的通知合并机制原理如下：

a）将所有成员加入到待通知队列中（如已存在则更新通知消息时间）；

b）下发线程，轮训获取待通知队列；

c）向队列中用户下发通知拉取。

通过通知合并机制，我们可以可保障下发线程一轮只会向同一用户发送一个通知拉取，即多个消息会合并为一个通知拉取，从面有效提升了服务端性能且降低了客户端与服务端的网络消耗。

我们的消息拉取流程主要是以下几步：

1）用户 B 收到通知后将向服务端发送拉取消息请求；

2）该请求将由“消息服务-1”节点处理；

3）“消息服务-1”将根据客户端传递的最后一条消息时间戳，从消息队列中返回消息列表；

4）用户 B 获取到新的消息。

对于直播间中的用户来说，很多消息其实并没有太多实际意义，比如大量重复的刷屏消息和动态通知等等，为了提升用户体验，这类消息是可以有策略地进行丢弃的（这是跟IM中的实时聊天消息最大的不同，IM中是不允许丢消息的）。

PS：直播间中消息分发的丢弃策略，跟上节中的通知合并机制一起，使得直接间海量消息的稳定、流畅分发得以成为可能。

我们的丢弃策略主要由以下3部分组成：

1）上行限速控制（丢弃）策略；

2）下行限速控制（丢弃）策略；

3）重要消息防丢弃策略。

我们来逐个解释一下。

1）上行限速控制（丢弃）策略：

针对上行的限速控制，我们默认是 200 条/秒，根据业务需要可调整。达到限速后发送的消息将在直播间服务丢弃，不再向各消息服务节点同步。

2）下行限速控制（丢弃）策略：

针对下行的限速控制，即对消息环形队列（见“5.2 消息拉取流程”中的拉取消息详细逻辑图）长度的控制，达到最大值后最“老”的消息将被淘汰丢弃。

每次下发通知拉取后服务端将该用户标记为“拉取中”，用户实际拉取消息后移除该标记。

拉取中标记的作用：例如产生新消息时用户具有拉取中标记，如果距设置标记时间在 2 秒内则不会下发通知（降低客户端压力，丢弃通知未丢弃消息），超过 2 秒则继续下发通知（连续多次通知未拉取则触发用户踢出策略，不在此赘述）。

因此消息是否被丢弃取决于客户端拉取速度（受客户端性能、网络影响），客户端及时拉取消息则没有被丢弃的消息。

3）重要消息防丢弃策略：

如前文所述：在直播间场景下对某些消息应具有较高优先级，不应丢弃。

例如：直播间的房间管理员进行操作后的通知消息或者系统通知。

针对此场景：我们设置了消息白名单、消息优先级的概念，保障不丢弃。如本节开始的图所示，消息环形队列可以为多个，与普通直播间消息分开则保障了重要消息不丢弃。