共计 6670 个字符，预计需要花费 17 分钟才能阅读完成。
本文由融云技术团队原创分享，有订正和改变。
1、引言
在视频直播场景中，弹幕交互、与主播的聊天、各种业务指令等等，组成了普通用户与主播之间的互动形式。
从技术的角度来看，这些实时互动伎俩，底层逻辑都是实时聊天音讯或指令的散发，技术架构类比于 IM 利用的话，那就相当于 IM 聊天室性能。
本系列文章的上篇《百万人在线的直播间实时聊天音讯散发技术实际》次要分享的是音讯散发和抛弃策略。本文将次要从高可用、弹性扩缩容、用户治理、音讯散发、客户端优化等角度，分享直播间海量聊天音讯的架构设计技术难点的实践经验。
学习交换：
- 挪动端 IM 开发入门文章：《新手入门一篇就够：从零开发挪动端 IM》
- 开源 IM 框架源码：https://github.com/JackJiang2…
（本文已同步公布于：http://www.52im.net/thread-38…）
2、系列文章
本文是系列文章中的第 7 篇：
《直播零碎聊天技术(一)：百万在线的美拍直播弹幕零碎的实时推送技术实际之路》
《直播零碎聊天技术(二)：阿里电商 IM 音讯平台，在群聊、直播场景下的技术实际》
《直播零碎聊天技术(三)：微信直播聊天室单房间 1500 万在线的音讯架构演进之路》
《直播零碎聊天技术(四)：百度直播的海量用户实时音讯零碎架构演进实际》
《直播零碎聊天技术(五)：微信小游戏直播在 Android 端的跨过程渲染推流实际》
《直播零碎聊天技术(六)：百万人在线的直播间实时聊天音讯散发技术实际》
《直播零碎聊天技术(七)：直播间海量聊天音讯的架构设计难点实际》（* 本文）
3、直播间的次要性能和技术特色
现在的视频直播间早已不单纯是视频流媒体技术问题，它还蕴含了用户可感知的多类型音讯发送和治理、用户治理等工作。在万物皆可直播的当下，超大型直播场景不足为奇，甚至呈现了人数无下限的场景，面对如此海量实时音讯和指令的并发挑战，带来的技术难度已非常规伎俩所能解决。
咱们先来演绎一下现在的典型视频直播间，相较于传统直播间所蕴含的次要性能特色、技术特色等。
丰盛的音讯类型和进阶性能：
1）可发送文字、语音、图片等传统聊天性能；
2）可实现点赞、礼物等非传统聊天性能的音讯类型；
3）可治理内容平安，包含敏感词设置，聊天内容反垃圾处理等。
聊天治理性能：
1）用户治理：包含创立、退出、销毁、禁言、查问、封禁（踢人）等；
2）用户白名单：白名单用户处于被爱护状态不会被主动踢出，且发送音讯优先级别最高；
3）音讯治理：包含音讯优先级、音讯散发管制等；
4）实时统计及音讯路由等能力。
人数下限和行为特色：
1）人数没有下限：一些大型直播场景，如春晚、国庆大阅兵等，直播间累计观看动辄上千万人次，同时观看人数也可达数百万；
2）用户进退行为：用户进出直播间十分频繁，高热度直播间的人员进出秒并发可能上万，这对服务撑持用户高低线以及用户治理的能力提出了十分大的挑战。
海量音讯并发：
1）音讯并发量大：直播聊天室人数没有显著下限，带来了海量并发音讯的问题（一个百万人数的聊天室，音讯的上行已是巨量，音讯散发量更是几何级回升）；
2）音讯实时性高：如果服务器只做音讯的消峰解决，峰值音讯的沉积会造成整体音讯延时增大。
针对上述第 2）点，延时的累积效应会导致音讯与直播视频流在工夫线上产生偏差，进而影响用户观看直播时互动的实时性。所以，服务器的海量音讯疾速散发能力非常重要。
4、直播间聊天室的架构设计
高可用零碎须要反对服务故障主动转移、服务精准熔断降级、服务治理、服务限流、服务可回滚、服务主动扩容 / 缩容等能力。
以服务高可用为指标的直播间聊天室零碎架构如下：
如上图所示，零碎架构次要分三层：
1）连贯层：次要治理服务跟客户端的长链接；
2）存储层：以后应用的是 Redis，作为二级缓存，次要存储聊天室的信息（比方人员列表、黑白名单、封禁列表等，服务更新或重启时，能够从 Redis 中加载出聊天室的备份信息）；
3）业务层：这是整个聊天室的外围，为了实现跨机房容灾，将服务部署在多个可用区，并依据能力和职责，将其分为聊天室服务和音讯服务。
聊天室服务和音讯服务的具体职责：
1）聊天室服务：次要负责解决治理类申请，比方聊天室人员的进出、封禁 / 禁言、上行音讯解决审核等；
2）音讯服务：次要缓存本节点须要解决的用户信息以及音讯队列信息，并负责聊天室音讯的散发。
在海量用户高并发场景下，音讯散发能力将决定着零碎的性能。以一个百万级用户量的直播间聊天室为例，一条上行音讯对应的是百万倍的散发。这种状况下，海量音讯的散发，依附单台服务器是无奈实现的。
咱们的优化思路是：将一个聊天室的人员分拆到不同的音讯服务上，在聊天室服务收到音讯后向音讯服务扩散，再由音讯服务分发给用户。
以百万在线的直播间聊天室为例：假如聊天室音讯服务共 200 台，那均匀每台音讯服务治理 5000 人左右，每台音讯服务在散发音讯时只须要给落在本台服务器上的用户散发即可。
服务落点的抉择逻辑：
1）在聊天室服务中：聊天室的上行信令是根据聊天室 ID 应用一致性哈希算法来抉择节点的；
2）在音讯服务中：根据用户 ID 应用一致性哈希算法来决定用户具体落在哪个音讯服务。
一致性哈希抉择的落点绝对固定，能够将聊天室的行为汇聚到一个节点上，极大晋升服务的缓存命中率。
聊天室人员进出、黑 / 白名单设置以及音讯发送时的判断等解决间接拜访内存即可，毋庸每次都拜访第三方缓存，从而进步了聊天室的响应速度和散发速度。
最初：Zookeeper 在架构中次要用来做服务发现，各服务实例均注册到 Zookeeper。
5、直播间聊天室的扩缩容能力
5.1 概述
随着直播这种模式被越来越多人承受，直播间聊天室面对人数激增以致服务器压力逐渐增大的状况越来越多。所以，在服务压力逐渐增大 / 缩小的过程中是否进行平滑的扩 / 缩容十分重要。
在服务的主动扩缩容方面，业内提供的计划大体一致：即通过压力测试理解单台服务器的瓶颈点 → 通过对业务数据的监控来判断是否须要进行扩缩 → 触发设定的条件后报警并主动进行扩缩容。
鉴于直播间聊天室的强业务性，具体执行中应该保障在扩缩容中整体聊天室业务不受影响。
5.2 聊天室服务扩缩容
聊天室服务在进行扩缩容时，咱们通过 Redis 来加载成员列表、封禁 / 黑白名单等信息。
须要留神的是：在聊天室进行主动销毁时，需先判断以后聊天室是否应该是本节点的。如果不是，跳过销毁逻辑，防止 Redis 中的数据因为销毁逻辑而失落。
聊天室服务扩缩容计划细节如下图所示：
5.3 音讯服务扩缩容
音讯服务在进行扩缩容时，大部分成员须要依照一致性哈希的准则路由到新的音讯服务节点上。这个过程会突破以后的人员均衡，并做一次整体的人员转移。
1）在扩容时：咱们依据聊天室的沉闷水平逐渐转移人员。
2）在有音讯时：[音讯服务会遍历缓存在本节点上的所有用户进行音讯的告诉拉取，在此过程中判断此用户是否属于这台节点（如果不是，将此用户同步退出到属于他的节点）。
3）在拉音讯时：用户在拉取音讯时，如果本机缓存列表中没有该用户，音讯服务会向聊天室服务发送申请确认此用户是否在聊天室中（如果在则同步退出到音讯服务，不在则间接丢掉）。
4）在缩容时：音讯服务会从公共 Redis 取得全副成员，并依据落点计算将本节点用户筛选进去并放入用户治理列表中。
6、海量用户的高低线和治理
聊天室服务：治理了所有人员的进出，人员的列表变动也会异步存入 Redis 中。
音讯服务：则保护属于本人的聊天室人员，用户在被动退出和退出房间时，须要依据一致性哈希算出落点后同步给对应的音讯服务。
聊天室取得音讯后：聊天室服务播送给所有聊天室音讯服务，由音讯服务进行音讯的告诉拉取。音讯服务会检测用户的音讯拉取状况，在聊天室沉闷的状况下，30s 内人员没有进行拉取或者累计 30 条音讯没有拉取，音讯服务会判断以后用户曾经离线，而后踢出此人，并且同步给聊天室服务对此成员做下线解决。
7、海量聊天音讯的散发策略
直播间聊天室服务的音讯散发及拉取计划如下图：
7.1 音讯告诉的拉取
在上图中：用户 A 在聊天室中发送一条音讯，首先由聊天室服务解决，聊天室服务将音讯同步到各音讯服务节点，音讯服务向本节点缓存的所有成员下发告诉拉取（图中服务器向用户 B 和用户 Z 下发了告诉）。
在音讯散发过程中，server 做了告诉合并。
告诉拉取的具体流程为：
1）客户端胜利退出聊天，将所有成员退出到待告诉队列中（如已存在则更新告诉音讯工夫）；
2）下发线程，轮训获取待告诉队列；
3）向队列中用户下发告诉拉取。
通过这个流程可保障下发线程一轮只会向同一用户发送一个告诉拉取（即多个音讯会合并为一个告诉拉取），无效晋升了服务端性能且升高了客户端与服务端的网络耗费。
7.2 音讯的拉取
用户的音讯拉取流程如下图：
如上图所示，用户 B 收到告诉后向服务端发送拉取音讯申请，该申请最终将由音讯节点 1 进行解决，音讯节点 1 将依据客户端传递的最初一条音讯工夫戳，从音讯队列中返回音讯列表（参考下图）。
客户端拉取音讯示例：
用户端本地最大工夫为 1585224100000，从 server 端能够拉取到比这个数大的两条音讯。
7.3 音讯控速
服务器应答海量音讯时，须要做音讯的控速解决。
这是因为：在直播间聊天室中，大量用户在同一时段发送的海量音讯，个别状况下内容基本相同。如果将所有音讯全局部发给客户端，客户端很可能呈现卡顿、音讯提早等问题，重大影响用户体验。
所以服务器对音讯的上下行都做了限速解决。
音讯控速原理：
具体的限速控制策略如下：
1）服务器上行限速管制（抛弃）策略：针对单个聊天室的音讯上行的限速管制，咱们默认为 200 条 / 秒，可依据业务须要调整。达到限速后发送的音讯将在聊天室服务抛弃，不再向各音讯服务节点同步；
2）服务器上行限速（抛弃）策略：服务端的上行限速管制，次要是依据音讯环形队列的长度进行管制，达到最大值后最“老”的音讯将被淘汰抛弃。
每次下发告诉拉取后服务端将该用户标记为拉取中，用户理论拉取音讯后移除该标记。
如果产生新音讯时用户有拉取中标记：
1）距设置标记工夫在 2 秒内，则不会下发告诉（升高客户端压力，抛弃告诉未抛弃音讯）；
2）超过 2 秒则持续下发告诉（间断屡次告诉未拉取则触发用户踢出策略，不在此赘述）。
因而：音讯是否被抛弃取决于客户端拉取速度（受客户端性能、网络影响）, 客户端及时拉取音讯则没有被抛弃的音讯。
8、直播间聊天室的音讯优先级
音讯控速的外围是对音讯的取舍，这就须要对音讯做优先级划分。
划分逻辑大抵如下：
1）白名单音讯：这类音讯最为重要，级别最高，个别零碎类告诉或者治理类信息会设置为白名单音讯；
2）高优先级音讯：仅次于白名单音讯，没有非凡设置过的音讯都为高优先级；
3）低优先级音讯：最低优先级的音讯，这类音讯大多是一些文字类音讯。
具体如何划分，应该是能够凋谢出不便的接口进行设置的。
服务器对三种音讯执行不同的限速策略，在高并发时，低优先级音讯被抛弃的概率最大。
服务器将三种音讯别离存储在三个音讯桶中：客户端在拉取音讯时依照白名单音讯 > 高优先级音讯 > 低优先级音讯的程序拉取。
9、客户端针对大量音讯的接管和渲染优化
9.1 音讯的接管优化
在音讯同步机制方面，如果直播间聊天室每收到一条音讯都间接下发到客户端，无疑会给客户端带来极大性能挑战。特地是在每秒几千或上万条音讯的并发场景下，继续的音讯解决会占用客户端无限的资源，影响用户其它方面的互动。
思考到以上问题，为聊天室独自设计了告诉拉取机制，由服务端进行一系列分频限速聚合等管制后，再告诉客户端拉取。
具体分为以下几步：
1）客户端胜利退出聊天室；
2）服务端下发告诉拉取信令；
3）客户端依据本地存储的音讯最大工夫戳，去服务端拉取音讯。
这里须要留神的是：首次退出直播间聊天室时，本地并没有无效工夫戳，此时会传 0 给服务拉取最近 50 条音讯并存库。后续再次拉取时才会传递数据库里存储的音讯的最大工夫戳，进行差量拉取。
客户端拉取到音讯后：会进行排重解决，而后将排重后的数据上抛业务层，以防止下层反复显示。
另外：直播间聊天室中的音讯即时性较强，直播完结或用户退出聊天室后，之前拉取的音讯大部分不须要再次查看，因而在用户退出聊天室时，会革除数据库中该聊天室的所有音讯，以节约存储空间。
9.2 音讯的渲染优化
在音讯渲染方面，客户端也通过一系列优化保障在直播间聊天室大量音讯刷屏的场景下仍有不俗的体现。
以 Andriod 端为例，具体的措施有：
1）采纳 MVVM 机制：将业务解决和 UI 刷新严格辨别。每收到一条音讯，都在 ViewModel 的子线程将所有业务解决好，并将页面刷新须要的数据筹备结束后，才告诉页面刷新；
2）升高主线程累赘：准确应用 LiveData 的 setValue() 和 postValue() 办法：曾经在主线程的事件通过 setValue() 形式告诉 View 刷新，以防止过多的 postValue() 造成主线程负担过重；
3）缩小非必要刷新：比方在音讯列表滑动时，并不需要将接管到的新音讯刷新进去，仅进行提醒即可；
4）辨认数据的更新：通过谷歌的数据比照工具 DiffUtil 辨认数据是否有更新，仅更新有变更的局部数据；
5）管制全局刷新次数：尽量通过部分刷新进行 UI 更新。
通过以上机制：从压测后果看，在中端手机上，直播间聊天室中每秒 400 条音讯时，音讯列表依然体现晦涩，没有卡顿。
10、针对传统聊天音讯外的自定义属性优化
10.1 概述
在直播间聊天室场景中，除了传统的聊天音讯收发以外，业务层常常须要有本人的一些业务属性，如在语音直播聊天室场景中的主播麦位信息、角色治理等，还有狼人杀等卡牌类游戏场景中记录用户的角色和牌局状态等。
绝对于传统聊天音讯，自定义属性有必达和时效的要求，比方麦位、角色等信息须要实时同步给聊天室的所有成员，而后客户端再依据自定义属性刷新本地的业务。
10.2 自定义属性的存储
自定义属性是以 key 和 value 的模式进行传递和存储的。自定义属性的操作行为次要有两种：即设置和删除。
服务器存储自定义属性也分两局部：
1）全量的自定义属性汇合；
2）自定义属性汇合变更记录。
自定义属性存储构造如下图所示：
针对这两份数据，应该提供两种查问接口，别离是查问全量数据和查问增量数据。这两种接口的组合利用能够极大晋升聊天室服务的属性查问响应和自定义散发能力。
10.3 自定义属性的拉取
内存中的全量数据，次要给从未拉取过自定义属性的成员应用。刚进入聊天室的成员，间接拉取全量自定义属性数据而后展现即可。
对于曾经拉取过全量数据的成员来说，若每次都拉取全量数据，客户端想取得本次的批改内容，就须要比对客户端的全量自定义属性与服务器端的全量自定义属性，无论比对行为放在哪一端，都会减少肯定的计算压力。
所以：为了实现增量数据的同步，构建一份属性变更记录汇合十分必要。这样：大部分成员在收到自定义属性有变更来拉取时，都能够取得增量数据。
属性变更记录采纳的是一个有序的 map 汇合：key 为变更工夫戳，value 里存着变更的类型以及自定义属性内容，这个有序的 map 提供了这段时间内所有的自定义属性的动作。
自定义属性的散发逻辑与音讯统一：均为告诉拉取。即客户端在收到自定义属性变更拉取的告诉后，带着本人本地最大自定义属性的工夫戳来拉取。比方：如果客户端传的工夫戳为 4，则会拉取到工夫戳为 5 和工夫戳为 6 的两条记录。客户端拉取到增量内容后在本地进行回放，而后对本人本地的自定义属性进行批改和渲染。
11、多人群聊参考资料
[1] IM 单聊和群聊中的在线状态同步应该用“推”还是“拉”？
[2] IM 群聊音讯如此简单，如何保障不丢不重？
[3] 挪动端 IM 中大规模群音讯的推送如何保障效率、实时性？
[4] 古代 IM 零碎中聊天音讯的同步和存储计划探讨
[5] 对于 IM 即时通讯群聊音讯的乱序问题探讨
[6] IM 群聊音讯的已读回执性能该怎么实现？
[7] IM 群聊音讯到底是存 1 份(即扩散读) 还是存多份(即扩散写)？
[8] 一套高可用、易伸缩、高并发的 IM 群聊、单聊架构方案设计实际
[9] IM 群聊机制，除了循环去发消息还有什么形式？如何优化？
[10] 网易云信技术分享：IM 中的万人群聊技术计划实际总结
[11] 阿里钉钉技术分享：企业级 IM 王者——钉钉在后端架构上的过人之处
[12] IM 群聊音讯的已读未读性能在存储空间方面的实现思路探讨
[13] 企业微信的 IM 架构设计揭秘：音讯模型、万人群、已读回执、音讯撤回等
[14] 融云 IM 技术分享：万人群聊音讯投递计划的思考和实际
（本文已同步公布于：http://www.52im.net/thread-38…）
