本文原题“百度直播音讯服务架构实际”，由百度 APP 音讯中台团队原创分享于“百度 Geek 说”公众号，为了让文章内容更通俗易懂，本次已做排版优化和内容从新划分，原文链接在文末。
1、引言
一套残缺的直播系统核心性能有两个：
1）实时音视频的推拉流；
2）直播间音讯流的收发（包含聊天音讯、弹幕、指令等）。
本文次要分享的是百度直播的音讯零碎的架构设计实际和演进过程。
实际上：直播间内用户的聊天互动，尽管模式上是常见的 IM 聊天音讯流，但直播音讯流不仅仅是用户聊天。
除用户聊天外：直播间内常见的用户送礼物、进场、点赞、去购买、主播举荐商品、申请连麦等互动行为的实时揭示，也是通过音讯流下发的。
此外：直播间敞开、直播流切换等非凡场景，也依赖音讯流的实时下发。
所以，直播零碎内的音讯流能够认为是直播间内主播与用户间实时互动和直播间实时控制的根底能力，也是零碎撑持。如果说实时音视频推拉流是直播零碎的灵魂，那音讯流能够说是直播零碎的骨架，它的重要性显而易见。
那么，如何构建直播的音讯零碎，又有哪些挑战须要解决，借着本文咱们一起来梳理一下。
学习交换：
- 即时通讯 / 推送技术开发交换 5 群：215477170 [举荐]
- 挪动端 IM 开发入门文章：《新手入门一篇就够：从零开发挪动端 IM》
- 开源 IM 框架源码：https://github.com/JackJiang2…
（本文同步公布于：http://www.52im.net/thread-35…
2、系列文章
本文是系列文章中的第 4 篇：
《直播零碎聊天技术(一)：百万在线的美拍直播弹幕零碎的实时推送技术实际之路》
《直播零碎聊天技术(二)：阿里电商 IM 音讯平台，在群聊、直播场景下的技术实际》
《直播零碎聊天技术(三)：微信直播聊天室单房间 1500 万在线的音讯架构演进之路》
《直播零碎聊天技术(四)：百度直播的海量用户实时音讯零碎架构演进实际》（* 本文）
3、与一般 IM 群聊的区别
直播间内的聊天音讯，常常被类比于一般的 IM 群聊性能。
群聊是大家比拟相熟的即时通讯（IM）场景，直播间内聊天和群聊，二者有相似性，但也有实质的区别。
比照二者的特点，直播音讯与 IM 群聊次要有以下区别：
1）参加人数不同：IM 群聊的参加人数上千人就是很大的群了。但对于高热度的大型直播场景，例如国庆、阅兵、春晚等，单直播间累计用户是百万甚至千万量级的汇合，同时在线人数可达数百万人。
2）组织关系不同：IM 用户进群退群，是绝对低频的操作，用户汇合绝对固定，用户进出的变更频度不会特地高。而用户进出直播间，是十分频繁的，高热度直播的单直播间每秒面临上万用户的进出变更。
3）持续时间不同：IM 群聊建设后，聊天持续时间可能比拟长，几天到数月都有。而直播间大部分继续不超过几个小时。
4、核心技术挑战
依据上节中，直播音讯和 IM 通聊的类比剖析，针对直播中的音讯零碎，咱们能够提炼出两个核心技术挑战。
挑战一：直播间内用户的保护
1）单直播间每秒上万用户的进出变更（理论进入直播间峰值不超过 2 万 QPS，退出也不超过 2 万 QPS）；
2）单直播间同时数百万用户在线；
3）单直播间累计用户达千万量级。
反对在线百万、累积千万两个汇合，每秒 4 万 QPS 更新，有肯定压力，但有反对高读写性能的存储应该能够解决，例如 redis。
挑战二：百万在线用户的音讯下发
面对百万在线用户，上下行都有大量的音讯，从直播用户端视角剖析：
1）音讯的实时性：如果音讯服务端做简略消峰解决，峰值音讯的沉积，会造成整体音讯延时增大，且延时可能产生很大的累积效应，音讯与直播视频流在工夫线上产生很大的偏差，影响用户观看直播时互动的实时性；
2）端体验和性能：端展现各类用户聊天和零碎音讯，个别一屏不超过 10-20 条。如果每秒有超过 20 条的音讯下发，端上展现的音讯根本会继续刷屏。再思考到有礼物音讯的特效等，大量的音讯，对端的解决和展现，带来继续高负荷。所以，对于一个长时间观看直播的用户端来说，如果呈现继续的大量音讯，端的音讯生产会有显著的性能压力，且过多音讯会有累积效应。
因为技术挑战一不难解决，以下内容次要探讨技术挑战二。
5、技术设计指标
综合思考上节的技术挑战和直播业务场景，咱们对于音讯零碎的需要指标有比拟显著的指标定义。
技术设计指标定义大抵如下：
1）实时性方面：端和端的音讯要达到秒级；
2）性能方面：音讯服务能反对同一直播间内百万以上用户同时在线下发；
3）峰值解决：对于峰值时的过多音讯，抛弃是正当适当的解决形式；
4）基于正当的端用户体验，单直播间内每秒音讯数假如不超过 N 条。
当初：问题的外围是，如何做到把不超过 N 条的音讯，在 S 秒内，下发到直播间内的百万用户（假如 N<=20，S<=2）。
6、从一般 IM 群聊的技术实现上找灵感
6.1 一般 IM 群聊音讯收发剖析
IM 群聊数据流及压力点：
如上图所示，首先具体分析一下一般群聊的音讯收发流程：
1）对于群 group-1，调配一个群公共音讯信箱 group-mbox-1；
2）群 group- 1 内的用户 user-1，由手机端 APP- 1 上收回音讯 msg-1；
3）服务端接管到音讯 msg-1，查看 user- 1 是否有权限，如有权限，将 msg- 1 存储到群信箱 group-mbox-1，生成相应 msgID-1；
4）服务端查问 group- 1 对应的用户列表 groupUserList-1；
5）基于 groupUserList- 1 拆分出所有独立群用户：user-1、user-2 … user-n；
6）对于每一个用户 user- i 来说，须要查问用户 user- i 的所在设施 device-i-1、device-i-2、device-i-m（因为一个账号可能登录多个设施）；
7）对于每个设施 device-i- j 来说，长连贯通道都会建设一个独立的长连贯 connect- j 以服务于该设施；但因为 connect- j 是由端上 APP- 1 连贯到长连贯服务的，具备动态性，所以，查问 device-i- j 与 connect- j 的对应关系时，须要依赖一个路由服务 route 来实现查问；
8）在查得 connect- j 后，能够通过 connect- j 下发 msg- 1 的告诉 groupmsg-notify-1；
9）如果用户 user- i 正在应用 device-i- j 的手机端 APP-1，用户 user- i 就能够立刻从长连贯 connect- j 上收到 msg- 1 的告诉 groupmsg-notify-1；
10）在接管到 groupmsg-notify- 1 后，手机端 APP- 1 中的音讯 SDK 依据端本地历史音讯记录的最初一条音讯 latestMsg 对应的音讯 ID 即 latestMsgID，来向服务端发动拉音讯申请 fetchMsg，拉取 group- 1 中从 latestMsgID+ 1 到最新的所有音讯；
11）服务端收到拉音讯申请 fetchMsg 后，从 group-mbox- 1 中取出 latestMsgID+ 1 到最新的所有音讯，返回给端；如果音讯过多，可能须要端分页拉取；
12）端 APP- 1 拉取到 group- 1 中从 latestMsgID+ 1 到最新的所有音讯，能够做展现；在用户在会话中浏览后，须要设置所有新音讯的已读状态或者会话已读状态。
6.2 一般 IM 群聊次要压力
如果齐全重用一般群聊音讯的下发告诉到端拉取的全过程，对于 user- 1 发的一条音讯 msg-1，如果须要反对一个实时百万量级的群音讯，大略有以下几个每秒百万量级的挑战。
首先：秒级拆分出用户列表 groupUserList-1，须要秒级读出百万的用户列表数据，对于存储和服务是第一个百万级挑战。
第二：对于拆分出群中的所有独立用户 user-i，须要秒级查问出百万量级的 device-i-j，对于存储和服务是第二个百万级挑战。
第三：对于所有 device-i-j，通过动静路由服务 route，须要秒级查问出百万量级的 connect-j，对于存储和服务是第三个百万级挑战。
第四：对于通过长连贯 connect- j 下发时，须要反对秒级下发百万量级的群音讯告诉 groupmsg-notify- 1 到对应的 connect- j 上，对于长连贯服务是个百万级的挑战。
第五：对于收到音讯告诉的所有端 APP-1，须要反对百万 QPS 端从服务端拉取音讯申请 fetchMsg，对于音讯信箱服务，这是也是一个百万量级的挑战；思考到理论各端 latestMsgID 可能不同，可能的优化形式会更简单一些，带来的性能影响会更大。
第六：如果在绝大多数用户是在线聊天的场景，设置已读状态也会有百万量级 QPS 对服务端的压力。
显然：齐全重用群聊的音讯流程，对音讯服务和长连贯服务带来的压力是微小的。
6.3 一般 IM 群聊优化计划
IM 群聊数据流优化后的压力点：
如上图所示，当初咱们来剖析以上每个百万量级的挑战，是否有优化的空间：
1）对于①拆分用户列表和②查问用户对应设施，如果存储上将二者合并集中起来，也就是优化直播间内用户列表的存储，扩大设施信息，能够缩小一次 user->device 的百万 QPS 查问，能够优化；
2）对于④上行告诉和⑤端拉取 fetchMsg 的可靠消息拉取模式，思考到直播音讯容许局部折损抛弃，能够只做单向音讯下发，而不做拉取，对于大部分连贯放弃在线的用户，也是能够承受的。所以能够优化，只保留上行告诉（蕴含音讯体），而舍弃端拉取；
3）对于⑥音讯设置已读，直播场景下能够思考简化舍弃。
如上优化后，缩小了②⑤⑥三个百万量级压力申请，但还有①拆分用户列表③动静路由查问④长连贯下发，这三个百万量级步骤须要解决。
对于①拆分用户列表：反对百万量级用户列表查问，比拟惯例的思路是反对基于群 groupID 的批量查问，例如一次能够查出 100 个用户，1 万 QPS 查问就能够反对到百万；基于群 groupID 把用户数据的存储，扩散到多个主从实例和分片上，管制好打散粒度不呈现热点，根本能做到，只是存储资源可能耗费较多。
对于③动静路由查问：外表上看，面临的问题与①相似，但却有些不同。因为群的用户列表，是基于群 groupID 做 key，建设一个表或多个打散的表；而 device-i- j 的查问是齐全扩散的，也是须要批量查问能力，然而齐全扩散的设施信息查问，不能只针对特定 key 做优化，须要动静路由服务反对整体上达到百万 QPS 的查问性能。
对于④长连贯服务下发：因为长连贯服务不依赖内部的存储服务，如果整体要反对百万量级的下发能力，若长连贯单实例能反对 1 万的下发能力，整体上 100 个实例就能反对到百万量级下发。
基于以上剖析：反对百万量级的音讯下发，初见曙光。仿佛只有优化好用户列表、动静路由的存储 / 查问和长连贯的容量扩容，但所有的前提是须要耗费大量存储和机器资源。
思考到直播业务的理论状况，事实不容乐观：
1）一方面，平时没有热点直播时，可能单场直播并发在线用户数峰值不超过 1 万人，甚至不到 1000；在业务初期，整体直播在线用户峰值可能也不超过 10 万。这就意味着，为了反对百万量级的峰值，资源整体上有几十倍的冗余；
2）另一方面，如果忽然来了一场热度十分高的直播，可能须要反对的不只是 100 万量级音讯下发，可能是 500 万以上的量级（例如国庆阅兵、春晚等）。这样的话，每次大型直播得提前预估可能的在线用户峰值，如果超过以后设计容量，须要对①用户列表③动静路由查问④长连贯服务，别离扩容和压测；或者在可承受的状况下，做服务降级或拒绝服务。
而实际上：在线用户峰值量级很难预计精确，这样会造成理论资源利用率很低，扩缩容的操作频繁，运维老本高。是否抉择这个计划，也是很令人纠结。
6.4 一般群聊多群组计划
也有人提过拆分多个群组的计划。
例如：如果一个群组最多反对 1 万用户，开 100 个群就能够反对一百万用户；再建设一个虚构群，将这 100 个群关联起来，仿佛可行。
但如果仔细分析，会发现以上提到的几个问题：“①拆分用户列表、③动静路由查问、④长连贯下发”，高压力仍然存在，还是不可避免。
除此之外，多群组还会引入其余问题：
1）问题一：多群组音讯不同步。如果两个用户在一起看直播，而所属群不同，看到的音讯会齐全不同；
2）问题二：直播场景用户是动静进出的，也就是说群组成员十分不稳固，在线用户峰值稳定也比拟大。如果是依据在线人数增长，动静新开群组，可能第一个群用户曾经很多了，第二个群刚开始用户比拟少；或者，在峰值期间开了比拟多的群，随着热度升高用户来到，用户变得扩散，一些群的用户可能较稀少，聊天互动较少，这时须要缩容合并群。如何均衡多个群的用户，达到好的业务成果，也是比拟难做的。
基于以上剖析，咱们并没有抉择多群组计划。
7、基于组播 mcast 计划的音讯架构实际
通过上节中类比一般 IM 群聊音讯的架构设计，本节将介绍咱们反对实时高并发百万量级同时在线用户的直播音讯架构——组播 mcast 计划的提出及演变。
7.1 跳出原有框架思考
是否要采纳上节基于 IM 群聊的优化计划，还是能够另辟蹊径？
先临时抛开群收发音讯流程：对于音讯下发来说，如果肯定要说一个步骤是必不可少的，那肯定是长连贯下发这步了。没有通过长连贯下发，音讯就无奈最终达到用户。
当然有人说轮询拉取也能够代替长连贯下发，来获取音讯，但显然轮询拉取的性能压力和实时性与长连贯下发相比差很多，故不在探讨范畴。
如果能简化为：给长连贯服务下发音讯时指定一个相似的 groupID，长连贯服务能间接拆分到所有群组用户相干的长连贯 connect-j，就能够省略掉用户列表拆分和动静路由查问的百万量级查问。
这样的话：音讯下发的压力将次要由长连贯服务来接受，服务端也不须要对多个零碎扩容，直播音讯的优化可能会大为简化。
依据这个思路：相当于在长连贯服务中，对连贯 connect 也建设群组的概念。基于连贯组的构想，咱们设计了一套长连贯的组播 mcast 机制。
7.2 长连贯组播 mcast 基本概念
基本概念总结如下：
1）每个长连贯组播 mcast 有全局惟一的标识 mcastID；
2）长连贯组播 mcast 反对创立、删除、批改、查问等治理操作；
3）长连贯组播 mcast 是若干长连贯在线用户的连贯 connect 的汇合；
4）一个用户 user- i 在设施 device-i- j 上，对于特定利用 APP- k 来说，建设惟一的一个长连贯 connect-j-k（此处临时不区别登录用户和非登录用户）；
5）长连贯组播 mcast 与组内长连贯 connect-j- k 的关系保护，不须要额定的独立存储，是保护在每个长连贯服务的实例上。
7.3 长连贯组播 mcast 的路由概念
组播 mcast- m 的路由 route-m，是一个长连贯服务实例的汇合 LcsList，记录了所有退出 mcast- m 的长连贯 connect- i 所在长连贯服务实例 lcs-j。
7.4 长连贯组播 mcast 路由的记录保护
退出组播 mcast 的逻辑流程：
1）客户端调用音讯 sdk 退出 mcast-m；
2）音讯 sdk 通过长连贯，收回上行申请 mcastJoin（mcast-m）；
3）业务层收到来自长连贯实例 lcs- i 上的连贯 connect- i 的 mcastJoin 申请，校验 mcast- m 的合法性；
4）业务层申请路由层建设基于组播 mcast- m 的组播路由 mcastRoute-m，将长连贯实例 lcs- i 退出组播路由 mcastRoute- m 中；
5）业务层申请长连贯服务层，申请 mcastJoin 所在长连贯实例 lcs-i，将申请所在连贯 connect- i 退出到 mcastConnectList- m 中。
来到组播 mcast，与退出组播 mcast 根本相似，由客户端调用音讯 sdk 来到 mcast-m，收回上行申请 mcastLeave（mcast-m），长连贯服务端更新路由和 mcastConnectList- m 信息。
7.5 组播 mcast 音讯推送
组播 mcast 数据流及压力点：
基于组播 mcast 的长连贯音讯推送过程，是一个 1:M * 1:N 的扩散放大过程。
具体过程形容如下：
1）一条音讯 msg- 1 推送，目的地是 ID 为 mcast- m 组播；
2）后端业务模块依据目标 mcast-m，做一致性 hash 抉择出 mcast 路由散发模块实例 mcastRouter- i，发送 msg- 1 到 mcastRouter-i；
3）mcast 散发路由模块实例 mcastRouter-i，依据 mcast- m 的组播路由 mcastRoute-m，查找所对应的接入实例路由记录列表 mcastLcsList-m，拆分出 mcast- m 所有的长连贯接入实例 lcs-1..lcs-M，别离并发发送 msg- 1 到长连贯实例上；
4）一个长连贯服务实例 lcs-j，收到音讯 msg- 1 推送后，依据组播 mcast- m 查找组播连贯列表 mcastConnectList-m，查出 mcast- m 内所有的连贯 connect-m-1..connect-m-N，并发推送 msg- 1 到音讯客户端 sdk-m-1..sdk-m-N；
5）音讯客户端 sdk-m- o 收到 msg- 1 后，递交给下层业务（例如直播 sdk）。
7.6 组播 mcast 机制的性能评估
当初剖析一下以上的组播 mcast 机制的性能压力：
1）组播 mcast 的路由保护，次要压力在于 mcastJoin 和 mcastLeave，而 Join 的量级峰值申请很难超过 2 万 qps；拜访压力比百万低两个数量级；
2）组播 mcast 的音讯推送流程，在一级路由 mcastRoute 拆分到长连贯实例时，个别在几十到百量级，老本很低；
3）组播 mcast 在长连贯单实例内的音讯推送，是单过程内的多连贯并发发送，经优化后线上实测，在单实例放弃 25W 长连贯的状况下，单实例压测可达 8Wqps 的 mcast 稳固下发，激进按 5Wqps 容量评估；多个长连贯实例间，是齐全的并发，能够较容易的程度扩容。
综上可知：对于 100Wqps 的下发，20 个长连贯实例就能够齐全负荷(20*5W=100W)，且有肯定裕量。如果 500Wqps 的下发，也不超过 100 实例；1000W 的下发，如果以 8W 单实例较大的负荷承载，125 实例就能够反对。
看上去，基于以上组播 mcast 机制，咱们建设了一套高效的反对百万量级 QPS 的长连贯下发机制，以后长连贯服务的容量就能够反对，根本不必扩容。但是否能齐全满足直播业务场景需要，还须要进一步探讨。
7.7 音讯峰值问题
对于每秒 1 条音讯，扩散到 100W 用户，甚至 500W 用户，以上组播 mcast 机制仿佛都能应答。
但直播间内音讯的理论状况是：热门的直播每秒用户上行聊天音讯会有很多，除聊天音讯外，直播间还有人数、进场、点赞、分享等定期和不定期发送的很多品种零碎音讯。
如果假如每秒峰值有 100 条各类音讯：100W*100= 1 亿，简略按单实例 5Wqps 算，须要 2000 个实例能力反对，尽管比老的群聊零碎应该好很多，但零碎还是遇到大量资源冗余或应答峰值须要大量扩容的老问题。是否能有更好的解决形式？
这里咱们思考常见的一个优化思路，是通过批量聚合的模式来进步零碎性能。
如果将这 100 条音讯每秒聚合打包一次来对立下发，QPS 还是 100W，长连贯零碎的下发 QPS 不变，但每秒下发音讯量级能够达到 1 亿，这个聚合计划实测是可行的。
聚合模式，咱们付出的老本是音讯时延的回升，1 秒的聚合均匀时延减少 500ms，用户体验损失不算大，但零碎下发音讯量级能够晋升百倍，综合评估老本收益来看是正当的。思考到直播的理论场景，大多数场景下秒级的聚合和时延是能够承受的。
7.8 音讯带宽问题
如上节所剖析的，聚合延时下发，长连贯单实例 QPS 问题解决了，随之而来的是，长连贯单实例下发的带宽压力问题。
例如：长连贯单实例须要下发 10000 长连贯时，每秒 100 音讯，音讯均匀 2K 字节，理论带宽为 2K10010000*8=15625Mbps，这曾经超过单物理机的万兆网卡的带宽容量。
另一方面：从全局带宽来看，也高达 1.5Tbps，带宽资源对于机房进口也会带来压力，这样的带宽老本过高，须要削减带宽应用或有更好的代替计划。
面对下发数据量带宽耗费过大的问题，在不改变业务数据的前提下，咱们采纳了数据压缩的解决方案。
而压缩是 CPU 密集型的操作，因为直播业务的实时性，不能简略思考压缩比，在综合均衡压缩比、压缩时延和压缩 CPU 耗费后，调优压缩库后实测的均匀压缩比达到 6.7 : 1，数据量压缩到原来的 15% 左右，这样 15625Mbps*15%=2344Mbps=2.29Gbps。单机万兆网卡的带宽容量，最多承载 4.27 万的长连贯下发，尽管没有达到 5 万，根本也能够承受。
从全局带宽来看，峰值也削减到不超过 230Gbps，收益很显著。
7.9 客户端性能问题
进一步思考，直播场景下，不仅是有较高的峰值音讯量级，而是在直播过程中有继续的高音讯量级压力。这不仅对于服务端是压力，对于客户端来说也是个挑战。
继续的高音讯量级：
1）一方面客户端在接管、展现等方面有显著的压力；
2）另一方面直播界面上过多过快的音讯刷新，对于用户体验也是有害无益的。
所以：在综合均衡用户体验和客户端性能的根底上，音讯服务端减少了联合音讯优先级的分级频控限速机制，单用户客户端并不需要接受每秒 100 条的压力，削减每秒下发音讯后，长连贯单实例每秒下发 5 - 8 万长连贯，CPU 和带宽都是能够稳固反对的。
7.10 实时音讯问题
咱们提供了基于音讯优先级的实时下发机制：
1）对于高优音讯能够立刻触发聚合下发，不会减少聚合延时；
2）而对于一般中低优音讯，还是做延时聚合下发。
7.11 用户在线问题
组播 mcast 机制的出发点，在百万量级高并发在线的场景下，保障在线用户的音讯达到，容许不在线用户接管音讯的局部折损，付出正当的技术复杂度和老本，获得服务质量和性能均衡。
而针对在线用户的音讯达到，还有个关键问题是如何保障用户的长连贯在线。
为了晋升长连贯服务的接入稳定性和可达性，咱们在以下几个方面做了优化。
1）拜访点：
长连贯服务在国内三大运营商的华北华东华南区域均部署了接入点入口。针对有局部国外用户的直播场景，还减少了香港机房的独立接入点入口。
2）HTTPDNS：
针对局部用户的 DNS 劫持问题和解析谬误问题，音讯 SDK 接入了 HTTPDNS 服务并优化本地缓存，造成多级域名解析保障体系，晋升了域名解析的可靠性，缩小了 DNS 劫持和错误率（见《百度 APP 挪动端网络深度优化实际分享(一)：DNS 优化篇》）。
3）心跳优化：
长连贯的心跳是保活探活的重要伎俩，针对直播场景实时性高的特点，为了尽快发现长连贯断链，在组播 mcastJoin 后，长连贯心跳也调整为距离更短、服务端动静可控的智能心跳。
这样在及时发现连贯异样后，音讯 SDK 能够疾速被动从新建连。
4）断链复原：
在直播间用户已退出组播 mcast 的状况下，如果长连贯断链，长连贯服务端会被动或被动的触发革除组播 mcast 成员。
而长连贯重建连复原时，直播业务层也须要监听连贯复原信号，重新加入组播 mcast，以复原组播 mcast 的音讯通路。
7.12 小结一下
综上所述，组播 mcast 机制：
1）无效的解决了百万量级同时在线用户的音讯实时下发问题；
2）对于短时断链和音讯过多，容许局部音讯的抛弃；
3）满足了直播场景音讯的设计指标。
组播 mcast 机制特点是：
1）音讯服务和路由层压力较轻，整体压力只由长连贯层承载，易于程度扩容；
2）基于延时聚合下发，辅以压缩限速，能够很好的解决上行 QPS 与带宽的性能问题；
3）零碎整体上行的 QPS 和带宽是齐全可控的。100W 在线用户的上行最大 QPS 是 100W，500W 在线用户的上行最大 QPS 是 500W。单实例的下发能力 5 - 8 万 QPS 是稳固的。因而，能够很容易判断整体的零碎容量，非凡场景是否须要扩容；
4）mcast 机制尽管是针对直播场景提出的，但自身设计具备通用性，能够利用于其余须要实时在线大量用户分组的音讯推送场景。
8、基于组播 mcast 计划音讯架构的进一步拓展
在组播 mcast 机制解决了百万量级的在线用户实时音讯下发后，直播音讯的场景不断扩大，一直有直播翻新业务提出新的音讯需要。
相应的，组播 mcast 的服务机制也须要与时俱进，一直在深度和广度上拓展优化。以下重点介绍一下历史音讯和礼物音讯。
8.1 直播间历史音讯的反对
对于刚进入直播间的用户来说，须要看到一些最近的聊天记录，以加强聊天互动气氛并帮忙理解直播的停顿；对历史聊天记录感兴趣额用户，还能够追溯更多的音讯历史。这就产生了聊天历史的需要。
为了反对这类历史音讯的需要，拓展计划是对于每个组播 mcast 申请开明一个组播公共音讯信箱 mcast-mbox 服务。
逻辑是这样的：
1）对于用户音讯和其余有长久化须要的音讯，全副写入这个音讯信箱；
2）用户能够指定组播 mcastID，按工夫区间和要拉获得音讯条数，来获取组播 mcast 的历史音讯。
上面补充阐明一下音讯信息的概念和利用。
什么是音讯信箱服务的概念？
1）音讯信箱内的一条音讯 msg，有惟一的音讯标识符 msgID；
2）一条音讯 msg，还包含有发送方信息、接管方信息、音讯类型、音讯内容等字段，此处能够临时疏忽；
3）每条音讯能够设置过期工夫，音讯过期后不能拜访到；
4）每条音讯能够设置已读状态；
5）一个音讯信箱 mbox，有惟一的信箱标识符 mboxID；
6）一个音讯信箱 mbox 是一个容器，存储有序的音讯列表 msgList；音讯列表 msgList 按 msgID 排序的；
7）音讯信箱服务，对指定信箱 mbox 反对单条音讯或批量音讯的写入；
8）音讯信箱服务，对指定信箱 mbox 反对基于 msgID 的单条音讯或批量音讯的查找；
9）音讯信箱服务，对指定信息 mbox 反对从 msgID-begin 到 msgID-end 的范畴查找。
实际上，最罕用的就是基于 msgid 范畴的音讯拉取。这里的音讯信箱服务是工夫线 timeline 模型，有趣味的同学能够进一步参考工夫线 timeline 模型的相干信息（见《古代 IM 零碎中聊天音讯的同步和存储计划探讨》一文中的“4、Timeline 模型”一节）。
8.2 直播间礼物音讯的反对
礼物音讯：
礼物音讯场景剖析：
1）用户送礼给主播，主播侧须要尽快、牢靠地收到礼物音讯告诉，能力及时的给予用户反馈；
2）送出礼物的用户，本地就可及时展现礼物成果，无音讯告诉强诉求；
3）直播间内其余用户，须要收到礼物音讯，以展现礼物成果，晋升直播间互动气氛，激发其余用户送礼；
4）礼物音讯波及用户订单和购买行为，须要由服务端确认收回；
5）礼物音讯优先级显著高于其余聊天音讯、零碎音讯。
基于以上剖析，直播音讯提出以下技术拓展计划：
1）减少一个独立的可靠消息组播 mcast 通道（如图 4 中组播 mcast-2），专供高优可靠消息的收发；与其余一般音讯、零碎音讯在数据流层面隔离，缩小互相烦扰；
2）对于普通用户侧的端音讯 SDK，礼物音讯组播 mcast 通道尽管是新增独立通道，音讯收发逻辑与一般音讯组播 mcast 通道保持一致；
3）对于主播侧，端音讯 SDK 对于礼物音讯组播 mcast 通道，须要反对推拉联合模式，以保障礼物音讯的全副达到；即便有短暂的掉线，也须要取到全副礼物音讯；
4）对于主播侧，在极其状况下，如果长连贯建连有异样，音讯 SDK 能够通过短连贯接口轮询，来拉取礼物组播 mcast 信箱音讯来兜底。
基于以上独立的可靠消息组播 mcast 通道计划，在未剔除一些异样场景的状况下，如主播下线未关播、数据偶发打点失落等，礼物音讯的触达率已达到 99.9% 以上。
8.3 直播音讯其余方面的倒退
在百度直播的倒退历程中，直播音讯服务还面临着许多其余基础性问题和翻新业务带来的其余挑战。
当初这些问题都有了较好的解决方案，以下列举一些，供大家学习参考：
1）如何反对多种客户端场景，安卓、iOS、H5、小程序、PC；
2）如何反对同一场直播的音讯在百度 APP 和难看、全民、贴吧等矩阵 APP 的买通；
3）如何反对非登录用户：IM 个别是反对登录用户，而直播场景也须要反对非登录用户；
4）长连贯服务如果出了重大问题，是否有端获取音讯的降级通道；
5）直播音讯审核的机审人审如何做，如何反对先发后审和先审后发；
6）如何反对跨多个直播间的音讯；
7）直播音讯服务是如何反对翻新业务的，如答题直播、直播带货、直播连麦等。
限于篇幅，以上问题在此不再做具体探讨，有趣味同学欢送探讨。
9、回顾和瞻望
自百度直播上线以来几年间，直播音讯服务迎难而上，一路乘风破浪为百度直播保驾护航，为百度直播提供了松软的技术撑持和保障。
将来，在反对直播翻新业务、更细粒度的音讯分级服务、直播音讯根底服务的稳定性和性能等方面，直播音讯服务会持续致力，夯实根底，继续翻新，以反对直播业务更好更快的倒退。
附录：更多相干文章
[1] IM 群聊方面的文章：
《疾速裂变：见证微信弱小后盾架构从 0 到 1 的演进历程（一）》
《如何保障 IM 实时音讯的“时序性”与“一致性”？》
《IM 单聊和群聊中的在线状态同步应该用“推”还是“拉”？》
《IM 群聊音讯如此简单，如何保障不丢不重？》
《微信后盾团队：微信后盾异步音讯队列的优化降级实际分享》
《挪动端 IM 中大规模群音讯的推送如何保障效率、实时性？》
《古代 IM 零碎中聊天音讯的同步和存储计划探讨》
《对于 IM 即时通讯群聊音讯的乱序问题探讨》
《IM 群聊音讯的已读回执性能该怎么实现？》
《IM 群聊音讯到底是存 1 份 (即扩散读) 还是存多份(即扩散写)？》
《一套高可用、易伸缩、高并发的 IM 群聊、单聊架构方案设计实际》
《[技术脑洞] 如果把 14 亿中国人拉到一个微信群里技术上能实现吗？》
《IM 群聊机制，除了循环去发消息还有什么形式？如何优化？》
《网易云信技术分享：IM 中的万人群聊技术计划实际总结》
《阿里钉钉技术分享：企业级 IM 王者——钉钉在后端架构上的过人之处》
《IM 群聊音讯的已读未读性能在存储空间方面的实现思路探讨》
[2] 更多直播技术的文章：
《挪动端实时音视频直播技术详解（一）：开篇》
《挪动端实时音视频直播技术详解（二）：采集》
《挪动端实时音视频直播技术详解（三）：解决》
《挪动端实时音视频直播技术详解（四）：编码和封装》
《挪动端实时音视频直播技术详解（五）：推流和传输》
《挪动端实时音视频直播技术详解（六）：提早优化》
《实践联系实际：实现一个简略地基于 html]5 的实时视频直播》
《实时视频直播客户端技术盘点：Native、html]5、WebRTC、微信小程序》
《Android 直播入门实际：入手搭建一套简略的直播零碎》
《淘宝直播技术干货：高清、低延时的实时视频直播技术解密》
《技术干货：实时视频直播首屏耗时 400ms 内的优化实际》
《新浪微博技术分享：微博实时直播答题的百万高并发架构实际》
《实时音频的混音在视频直播中的技术原理和实际总结》
《七牛云技术分享：应用 QUIC 协定实现实时视频直播 0 卡顿！》
《近期大热的实时直播答题零碎的实现思路与技术难点分享》
《P2P 技术如何将实时视频直播带宽升高 75%？》
《网易云信实时视频直播在 TCP 数据传输层的一些优化思路》
《首次披露：快手是如何做到百万观众同场看直播仍能秒开且不卡顿的？》
《浅谈实时音视频直播中间接影响用户体验的几项要害技术指标》
《技术揭秘：反对百万级粉丝互动的 Facebook 实时视频直播》
《挪动端实时视频直播技术实际：如何做到实时秒开、晦涩不卡》
《实现提早低于 500 毫秒的 1080P 实时音视频直播的实际分享》
《浅谈开发实时视频直播平台的技术要点》
《海量实时音讯的视频直播零碎架构演进之路(视频 +PPT)[附件下载]》
《YY 直播在挪动弱网环境下的深度优化实际分享(视频 +PPT)[附件下载]》
《从 0 到 1：万人在线的实时音视频直播技术实际分享(视频 +PPT) [附件下载]》
《在线音视频直播室服务端架构最佳实际(视频 +PPT) [附件下载]》
本文已同步公布于“即时通讯技术圈”公众号。
▲ 本文在公众号上的链接是：点此进入。同步公布链接是：http://www.52im.net/thread-35…