共计 3527 个字符，预计需要花费 9 分钟才能阅读完成。
本文由融云技术团队原创分享，原题“聊天室海量音讯散发之音讯抛弃策略”，内容有订正。
1、引言
随着直播类利用的遍及，尤其直播带货概念的风靡，大用户量的直播间场景未然常态化。
大用户量直播间中的实时互动是十分频繁的，具体体现在技术上就是各种用户聊天、弹幕、礼物、点赞、禁言、零碎告诉等实时音讯。
如此大量的实时音讯，在散发时如何解决能力不至于把服务端搞垮，而到了客户端时也不至于让 APP 呈现疯狂刷屏和卡顿（不至于影响用户体验），这显然须要非凡的技术手段和实现策略能力应答。
其实，直播间中的实时音讯散发，在技术上是跟传统的在线聊天室这种概念是一样的，只是传统互联网时代，聊天室同时在线的用户量不会这么大而已，尽管量级不同，但技术模型是齐全能够套用的。
本文将基于直播技术实际的背景，分享了单直播间百万用户在线量的实时音讯散发的技术经验总结，心愿带给你启发。
学习交换：
- 挪动端 IM 开发入门文章：《新手入门一篇就够：从零开发挪动端 IM》
- 开源 IM 框架源码：https://github.com/JackJiang2…
（本文已同步公布于：http://www.52im.net/thread-37…）
2、系列文章
本文是系列文章中的第 6 篇：
《直播零碎聊天技术(一)：百万在线的美拍直播弹幕零碎的实时推送技术实际之路》
《直播零碎聊天技术(二)：阿里电商 IM 音讯平台，在群聊、直播场景下的技术实际》
《直播零碎聊天技术(三)：微信直播聊天室单房间 1500 万在线的音讯架构演进之路》
《直播零碎聊天技术(四)：百度直播的海量用户实时音讯零碎架构演进实际》
《直播零碎聊天技术(五)：微信小游戏直播在 Android 端的跨过程渲染推流实际》
《直播零碎聊天技术(六)：百万人在线的直播间实时聊天音讯散发技术实际》（* 本文）
3、技术挑战
咱们以一个百万人观看的直播间为例进行剖析，看看须要面临哪些技术挑战。
1）在直播中会有一波一波的音讯顶峰，比方直播中的“刷屏”音讯，即大量用户在同一时段发送的海量实时音讯，个别状况下此类“刷屏”音讯的音讯内容基本相同。如果将所有音讯全副展现在客户端，则客户端很可能呈现卡顿、音讯提早等问题，重大影响用户体验。
2）海量音讯的状况下，如果服务端每条音讯都长期存储将导致服务缓存使用量激增，使得内存、存储成为性能瓶颈。
3）在另外一些场景下，比方直播间的房间管理员进行操作后的告诉音讯或者零碎告诉，个别状况下这类音讯是较为重要的，如何优先保障它的达到率。
基于这些挑战，咱们的服务须要做一个基于业务场景的优化来应答。
4、架构模型
咱们的架构模型图如下：
如上图所示，上面将针对次要服务进行简要阐明。
1）直播间服务：
次要作用是：缓存直播间的根本信息。包含用户列表、禁言 / 封禁关系、白名单用户等。
2）音讯服务：
次要作用是：缓存本节点须要解决的用户关系信息、音讯队列信息等。
具体说是以下两个次要事件。
直播间用户关系同步：
a）成员被动退出退出时：直播间服务同步至 ==> 音讯服务；
b）散发音讯发现用户已离线时：音讯服务同步至 ==> 直播间服务。
发送音讯：
a）直播间服务通过必要校验通过后将音讯播送至音讯服务；
b）直播间服务不缓存音讯内容。
3）Zk（就是 Zookeeper 啦）：
次要作用就是：将各服务实例均注册到 Zk，数据用于服务间流转时的落点计算。
具体就是：
a）直播间服务：依照直播间 ID 落点；
b）音讯服务：依照用户 ID 落点。
4）Redis：
次要作为二级缓存，以及服务更新（重启）时内存数据的备份。
5、音讯散发总体方案
直播间服务的音讯散发残缺逻辑次要包含：音讯散发流程和音讯拉取流程。
5.1 音讯散发流程
如上图所示，咱们的音讯散发流程次要是以下几步：
1）用户 A 在直播间中发送一条音讯，首先由直播间服务解决；
2）直播间服务将音讯同步到各音讯服务节点；
3）音讯服务向本节点缓存的所有成员下发告诉拉取；
4）如上图中的“音讯服务 -1”，将向用户 B 下发告诉。
另外，因为音讯量过大，咱们在在散发的过程中，是具备告诉合并机制的，告诉合并机制次要提当初上述步骤 3 中。
上述步骤 3 的告诉合并机制原理如下：
a）将所有成员退出到待告诉队列中（如已存在则更新告诉音讯工夫）；
b）下发线程，轮训获取待告诉队列；
c）向队列中用户下发告诉拉取。
通过告诉合并机制，咱们能够可保障下发线程一轮只会向同一用户发送一个告诉拉取，即多个音讯会合并为一个告诉拉取，从面无效晋升了服务端性能且升高了客户端与服务端的网络耗费。
PS：以上告诉合并机制，在大音讯量的状况下，非常适合应用 Actor 分布式算法来实现，有趣味的同学能够进一步学习《分布式高并发下 Actor 模型如此优良》、《分布式计算技术之 Actor 计算模式》。
5.2 音讯拉取流程
如上图所示，咱们的音讯拉取流程次要是以下几步：
1）用户 B 收到告诉后将向服务端发送拉取音讯申请；
2）该申请将由“音讯服务 -1”节点解决；
3）“音讯服务 -1”将依据客户端传递的最初一条音讯工夫戳，从音讯队列中返回音讯列表（原理详见下图 ▼）；
4）用户 B 获取到新的音讯。
上述步骤 3 中拉取音讯的具体逻辑如下图所示：
6、音讯散发的抛弃策略
对于直播间中的用户来说，很多音讯其实并没有太多实际意义，比方大量反复的刷屏音讯和动静告诉等等，为了晋升用户体验，这类音讯是能够有策略地进行抛弃的（这是跟 IM 中的实时聊天音讯最大的不同，IM 中是不容许丢音讯的）。
PS：直播间中音讯散发的抛弃策略，跟上节中的告诉合并机制一起，使得间接间海量音讯的稳固、晦涩散发得以成为可能。
咱们的抛弃策略次要由以下 3 局部组成：
1）上行限速管制（抛弃）策略；
2）上行限速管制（抛弃）策略；
3）重要音讯防抛弃策略。
如下图所示：
咱们来一一解释一下。
1）上行限速管制（抛弃）策略：
针对上行的限速管制，咱们默认是 200 条 / 秒，依据业务须要可调整。达到限速后发送的音讯将在直播间服务抛弃，不再向各音讯服务节点同步。
2）上行限速管制（抛弃）策略：
针对上行的限速管制，即对音讯环形队列（见“5.2 音讯拉取流程”中的拉取音讯具体逻辑图）长度的管制，达到最大值后最“老”的音讯将被淘汰抛弃。
每次下发告诉拉取后服务端将该用户标记为“拉取中”，用户理论拉取音讯后移除该标记。
拉取中标记的作用：例如产生新音讯时用户具备拉取中标记，如果距设置标记工夫在 2 秒内则不会下发告诉（升高客户端压力，抛弃告诉未抛弃音讯），超过 2 秒则持续下发告诉（间断屡次告诉未拉取则触发用户踢出策略，不在此赘述）。
因而音讯是否被抛弃取决于客户端拉取速度（受客户端性能、网络影响），客户端及时拉取音讯则没有被抛弃的音讯。
3）重要音讯防抛弃策略：
如前文所述：在直播间场景下对某些音讯应具备较高优先级，不应抛弃。
例如：直播间的房间管理员进行操作后的告诉音讯或者零碎告诉。
针对此场景：咱们设置了音讯白名单、音讯优先级的概念，保障不抛弃。如本节开始的图所示，音讯环形队列能够为多个，与一般直播间音讯离开则保障了重要音讯不抛弃。
通过上述“1）上行限速管制（抛弃）策略”和“上行限速管制（抛弃）策略”保障了：
1）客户端不会因为海量音讯呈现卡顿、提早等问题；
2）避免出现音讯刷屏，肉眼无奈查看的状况；
3）同时升高了服务端存储压力，不会因为海量音讯呈现内存瓶颈从而影响服务。
7、写在最初
随着挪动互联网的倒退，直播间的实时音讯业务模型和压力也在不停地扩大变动，后续可能还会遇到更多的挑战，咱们的服务会与时俱进、跟进更优的计划策略进行应答。
附录：多人群聊天技术文章
[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-37…）
