【融云分析】聊天室海量消息分发之消息丢弃策略
1 背景
随着直播、聊天室等 APP 的广泛普及应用，聊天室功能越来越被重视。比如今年非常火、下载量飙升的『直播带货』类 APP，在其直播中的用户聊天、弹幕、礼物、点赞、禁言、系统通知等场景都基于聊天室实现；如果将聊天室中产生的海量消息全量分发至客户端，那么客户端可能会出现卡顿，且此类刷屏消息人眼无法查看也会影响用户体验，因此聊天室消息分发的丢弃策略应运而生。
2 海量消息分发的挑战
我们以一个百万人观看的直播聊天室模型进行举例：
1、在直播中会有一波一波的消息高峰，比如直播中的“刷屏”消息，即大量用户在同一时段发送的海量消息，一般情况下此类“刷屏”消息的消息内容基本相同。如果将所有消息全部展示在客户端，则客户端很可能出现卡顿、消息延迟等问题，严重影响用户体验。
2、海量消息的情况下，如果服务端每条消息都长期存储将导致服务缓存使用量激增，使得内存、存储成为性能瓶颈。
3、在另外一些场景下，比如聊天室的房间管理员进行操作后的通知消息或者系统通知，一般情况下这类消息是较为重要的，需要优先保障它的到达率。
基于这些挑战，我们的服务需要做一个基于业务场景的优化来应对。
3 聊天室架构模型
融云聊天室服务经过多年迭代更新，目前已非常稳定。以下简要介绍融云的聊天室架构，架构示意图如下：
简要说明：
聊天室服务-缓存聊天室的基本信息，包括用户列表，禁言封禁关系，白名单用户等
消息服务-缓存本节点需要处理的用户关系信息、消息队列信息等
* 聊天室用户关系同步：
成员主动加入退出时：聊天室服务同步至==> 消息服务
分发消息发现用户已离线时：消息服务同步至==> 聊天室服务
*发送消息：
聊天室服务经过必要校验通过后将消息广播至消息服务
聊天室服务不缓存消息内容
Zk-各服务实例均注册到 Zk，数据用于服务间流转时的落点计算
聊天室服务:按照聊天室 ID 落点
消息服务:按照用户 ID 落点
Redis-主要作为二级缓存，以及服务更新（重启）时内存数据的备份
4 聊天室消息分发解决方案
聊天室服务的消息分发、拉取方案：
分发（图4-1）：
- 用户 A 在聊天室中发送一条消息，首先由聊天室服务处理
- 聊天室服务将消息同步到各消息服务节点
- 消息服务向本节点缓存的所有成员下发通知拉取
- 如图『消息服务-1』将向用户 B 下发通知
另外，在分发过程中，具有通知合并机制；上述步骤 3 详细流程为：
- 将所有成员加入到待通知队列中（如已存在则更新通知消息时间）
- 下发线程，轮训获取待通知队列
- 向队列中用户下发通知拉取
通过次流程可保障下发线程一轮只会向同一用户发送一个通知拉取，即多个消息会合并为一个通知拉取，有效提升了服务端性能且降低了客户端与服务端的网络消耗。
拉取（图4-2）：
- 用户 B 收到通知后将向服务端发送拉取消息请求
- 该请求将由『消息服务-1』节点处理
- 『消息服务-1』将根据客户端传递的最后一条消息时间戳，从消息队列中返回消息列表，参考图 4-3 示意
- 用户 B 获取到新的消息
5 聊天室消息分发之消息丢弃策略
5.1上行限速控制（丢弃）策略：
针对上行的限速控制，默认 200 条/秒，根据业务需要可调整。达到限速后发送的消息将在聊天室服务丢弃，不再向各消息服务节点同步。
5.2下行限速控制（丢弃）策略：
针对下行的限速控制，即对消息环形队列（图 4.3 所描述拉取消息过程）长度的控制，达到最大值后最“老”的消息将被淘汰丢弃。
每次下发通知拉取后服务端将该用户标记为拉取中，用户实际拉取消息后移除该标记。拉取中标记作用：例如产生新消息时用户具有拉取中标记，如果距设置标记时间在 2 秒内则不会下发通知（降低客户端压力，丢弃通知未丢弃消息），超过 2 秒则继续下发通知（连续多次通知未拉取则触发用户踢出策略，不在此赘述）。因此消息是否被丢弃取决于客户端拉取速度（受客户端性能、网络影响），客户端及时拉取消息则没有被丢弃的消息。
通过以上两个策略保障了客户端不会因为海量消息出现卡顿、延迟等问题；避免出现消息刷屏，肉眼无法查看的情况；同时降低了服务端存储压力，不会因为海量消息出现内存瓶颈从而影响服务。
5.3 重要消息防丢弃策略：
如前文所述，在聊天室场景下对某些消息应具有较高优先级，不应丢弃；例如聊天室的房间管理员进行操作后的通知消息或者系统通知，针对此场景，我们设置了消息白名单、消息优先级的概念，保障不丢弃。如图 5-1 所示，消息环形队列可以为多个，与普通聊天室消息分开则保障了重要消息不丢弃。
6 结束语
随着移动互联网的发展，聊天室的业务模型和压力也在不停地扩展变化，后续可能还会遇到更多的挑战，我们的服务会与时俱进、跟进更优的方案策略进行应对。
最新活动推荐：
