百度直播消息服务架构实践

导读：直播业务的核心功能有两个，一个是实时音视频推拉流，另外一个是直播间消息流的收发。本文主要介绍百度直播服务内的消息服务系统的设计实践和演化。

1、背景

直播间内用户聊天互动，形式上是常见的IM消息流；但直播消息流不只仅是用户聊天。除用户聊天外，直播间内常见的用户送礼物、进场、点赞、去购买、主播推荐商品、申请连麦等互动行为的实时提醒，也是经过消息流下发的。此外，直播间关闭、直播流切换等特殊场景，也依赖消息流的实时下发。消息流能够认为是直播间内主播与用户间实时互动和直播间实时控制的基础能力。

2、直播消息1.0 - 奠基基础
如何构建直播的消息系统，又有哪些挑战须要解决，咱们来梳理一下。
2.1 直播消息场景分析
直播间内聊天消息，常常被类比于群聊。群聊是你们比较熟悉的即时通信场景，直播间内聊天和群聊，两者有类似性，但也有本质的区别。
对比两者的特色：

1. 同时参与人数不一样：群聊的参与人数上千人就是很大的群了；但对于高热度的大型直播场景，例如国庆、阅兵、春晚等，单直播间累计用户是百万甚至千万量级的集合，同时在线人数可达数百万人。
2. 用户与群和直播间的关系不一样：用户进群退群，是相对低频的操做，用户集合相对固定，用户进出的变动频度不会特别高；而用户进出直播间，是很是频繁的，高热度直播的单直播间每秒面临上万用户的进出变动。
3. 持续时间不一样：群聊创建后，聊天持续时间可能比较长，几天到数月都有；而直播间大部分持续不超过几个小时。

 根据以上分析，提炼出两个核心问题：
问题一：直播间内用户的维护

1. 单直播间每秒上万用户的进出变动；实际进入直播间峰值不超过2万QPS，退出也不超过2万QPS。
2. 单直播间同时数百万用户在线
3. 单直播间累计用户达千万量级

支持在线百万、累积千万两个集合，每秒4万QPS更新，有必定压力，但有支持高读写性能的存储应该能够解决，例如redis。 

问题二：百万在线用户的消息下发
面对百万在线用户，上下行都有大量的消息，从直播用户端视角分析：

1. 实时性：若是消息服务端作简单消峰处理，峰值消息的堆积，会形成总体消息延时增大，且延时可能产生很大的累积效应，消息与直播视频流在时间线上产生很大的误差，影响用户观看直播时互动的实时性。
2. 端体验和性能：端展现各种用户聊天和系统消息，通常一屏不超过10-20条；若是每秒有超过20条的消息下发，端上展现的消息基本会持续刷屏；再考虑到有礼物消息的特效等；大量的消息，对端的处理和展现，带来持续高负荷。因此，对于一个长时间观看直播的用户端来讲，若是出现持续的大量消息，端的消息消费会有显著的性能压力，且过多消息会有累积效应。

因为问题一不难解决，如下主要讨论问题二。

2.2 直播消息设计目标
综合考虑直播业务场景，对于消息服务的需求目标以下：

1. 实时性方面，端和端的消息要达到秒级；
2. 性能方面，消息服务能支持同一直播间内百万以上用户同时在线下发；
3. 而对于峰值的过多消息，丢弃是合理适当的处理方式；
4. 基于合理的端用户体验，单直播间内每秒消息数假设不超过N条。

如今，问题的核心是，如何作到把不超过N条的消息，在S秒内，下发到直播间内的百万用户，假设N<=20，S<=2。

2.3 普通群聊压力分析
2.3.1 普通群聊消息收发分析

△图1：群聊数据流及压力点

首先，具体分析一下普通群聊的消息收发流程：

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-一、user-2。。。user-n；
6. 对于每个用户user-i来讲，须要查询用户user-i的所在设备device-i-一、device-i-二、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到最新的全部消息，能够作展现；在用户在会话中阅读后，须要设置全部新消息的已读状态或者会话已读状态。

2.3.2 普通群聊主要压力
若是彻底重用普通群聊消息的下发通知到端拉取的全过程，对于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对服务端的压力。
显然，彻底重用群聊的消息流程，对消息服务和长链接服务带来的压力是巨大的。

2.3.3 普通群聊优化方案

△图2：群聊数据流优化后压力点 

如今，咱们来分析以上每一个百万量级的挑战，是否有优化的空间。

1. 对于①拆分用户列表和②查询用户对应设备，若是存储上将两者合并集中起来，也就是优化直播间内用户列表的存储，扩展设备信息，能够减小一次user->device的百万QPS查询，能够优化。
   
2. 对于④下行通知和⑤端拉取fetchMsg的可靠消息拉取模式，考虑到直播消息容许部分折损丢弃，能够只作单向消息下发，而不作拉取，对于大部分链接保持在线的用户，也是能够接受的。因此能够优化，只保留下行通知（包含消息体），而舍弃端拉取。
   
3. 对于⑥消息设置已读，直播场景下能够考虑简化舍弃。
   

如上优化后，减小了②⑤⑥三个百万量级压力请求，但还有①拆分用户列表③动态路由查询④长链接下发，这三个百万量级步骤须要处理。
对于①拆分用户列表，支持百万量级用户列表查询，比较常规的思路是支持基于群groupID的批量查询，例如一次能够查出100个用户，1万QPS查询就能够支持到百万；基于群groupID把用户数据的存储，分散到多个主从实例和分片上，控制好打散粒度不出现热点，基本能作到，只是存储资源可能消耗较多。 
对于③动态路由查询，表面上看，面临的问题与①相似，但却有些不一样。由于群的用户列表，是基于群groupID作key，创建一个表或多个打散的表；而device-i-j的查询是彻底分散的，也是须要批量查询能力，可是彻底分散的设备信息查询，不能只针对特定key作优化，须要动态路由服务支持总体上达到百万QPS的查询性能。
对于④长链接服务下发，因为长链接服务不依赖外部的存储服务，若是总体要支持百万量级的下发能力，若长链接单实例能支持1万的下发能力，总体上100个实例就能支持到百万量级下发。
基于以上分析，支持百万量级的消息下发，初见曙光。彷佛只要优化好用户列表、动态路由的存储/查询和长链接的容量扩容，但全部的前提是须要消耗大量存储和机器资源。考虑到直播业务的实际状况，现实不容乐观：
一方面，平时没有热点直播时，可能单场直播并发在线用户数峰值不超过1万人，甚至不到1000；在业务初期，总体直播在线用户峰值可能也不超过10万。这就意味着，为了支持百万量级的峰值，资源总体上有几十倍的冗余。
另外一方面，若是忽然来了一场热度很是高的直播，可能须要支持的不仅是100万量级消息下发，多是500万以上的量级（例如国庆阅兵、春晚等）。这样的话，每次大型直播得提早预估可能的在线用户峰值，若是超过当前设计容量，须要对①用户列表③动态路由查询④长链接服务，分别扩容和压测；或者在可接受的状况下，作服务降级或拒绝服务。
而实际上，在线用户峰值量级很难估计准确，这样会形成实际资源利用率很低，扩缩容的操做频繁，运维成本高。是否选择这个方案，也是很使人纠结。
2.3.4 普通群聊多群组方案
也有人提过拆分多个群组的方案，例如，若是一个群组最多支持1万用户，开100个群就能够支持一百万用户；再创建一个虚拟群，将这100个群关联起来，彷佛可行。
但若是仔细分析，会发现以上提到的几个问题①拆分用户列表③动态路由查询④长链接下发，高压力依然存在，仍是不可避免。
除此以外，多群组还会引入其余问题：
问题一：多群组消息不一样步。若是两个用户在一块儿看直播，而所属群不一样，看到的消息会彻底不一样。
问题二：直播场景用户是动态进出的，也就是说群组成员很是不稳定，在线用户峰值波动也比较大。若是是根据在线人数增加，动态新开群组，可能第一个群用户已经不少了，第二个群刚开始用户比较少；或者，在峰值期间开了比较多的群，随着热度下降用户离开，用户变得分散，一些群的用户可能较稀少，聊天互动较少，这时须要缩容合并群。如何平衡多个群的用户，达到好的业务效果，也是比较难作的。
基于以上分析，咱们并无选择多群组方案。

2.4 组播mcast方案
支持实时高并发百万量级同时在线用户的直播消息架构，组播mcast方案的提出及演化。
2.4.1 跳出原有框架思考
是否要采用以上基于群聊的优化方案，仍是能够另辟蹊径？
先暂时抛开群收发消息流程，对于消息下发来讲，若是必定要说一个步骤是必不可少的，那必定是长链接下发这步了。没有经过长链接下发，消息就没法最终到达用户；固然有人说轮询拉取也能够替代长链接下发，来获取消息，但显然轮询拉取的性能压力和实时性与长链接下发相比差不少，故不在讨论范围。
若是能简化为，给长链接服务下发消息时指定一个相似的groupID，长链接服务能直接拆分到全部群组用户相关的长链接connect-j，就能够省略掉用户列表拆分和动态路由查询的百万量级查询。
这样的话，消息下发的压力将主要由长链接服务来承受，服务端也不须要对多个系统扩容，直播消息的优化可能会大为简化。
根据这个思路，至关于在长链接服务中，对链接connect也创建群组的概念。基于链接组的设想，咱们设计了一套长链接的组播mcast机制。
2.4.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的关系维护，不须要额外的独立存储，是维护在每一个长链接服务的实例上。

2.4.3 长链接组播mcast的路由概念
组播mcast-m的路由route-m，是一个长链接服务实例的集合LcsList，记录了全部加入mcast-m的长链接connect-i所在长链接服务实例lcs-j。
2.4.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信息。
2.4.5 组播mcast消息推送
△图3：组播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）。

2.4.6 组播mcast机制的性能评估
如今分析一下以上的组播mcast机制的性能压力：

1. 组播mcast的路由维护，主要压力在于mcastJoin和mcastLeave，而Join的量级峰值请求很难超过2万qps；访问压力比百万低两个数量级。
2. 组播mcast的消息推送流程，在一级路由mcastRoute拆分到长链接实例时，通常在几十到百量级，成本很低。
3. 组播mcast在长链接单实例内的消息推送，是单进程内的多链接并发发送，经优化后线上实测，在单实例保持25W长链接的状况下，单实例压测可达8Wqps的mcast稳定下发，保守按5Wqps容量评估；多个长链接实例间，是彻底的并发，能够较容易的水平扩容。
4. 综上可知，对于100Wqps的下发，20个长链接实例就能够彻底负荷(20*5W=100W)，且有必定裕量。若是500Wqps的下发，也不超过100实例；1000W的下发，若是以8W单实例较大的负荷承载，125实例就能够支持。
   

容量评估（实例数）	单实例1万qps	单实例5万qps	单实例8万qps
100万长链接	100	20	12.5
500万长链接	500	100	62.5
1000万长链接	1000	200	125

看上去，基于以上组播mcast机制，咱们创建了一套高效的支持百万量级QPS的长链接下发机制，当前长链接服务的容量就能够支持，基本不用扩容。可是否能彻底知足直播业务场景需求，还须要进一步讨论。
2.4.7 消息峰值问题
对于每秒1条消息，扩散到100W用户，甚至500W用户，以上组播mcast机制彷佛都能应对。
但直播间内消息的实际状况是，热门的直播每秒用户上行聊天消息会有不少，除聊天消息外，直播间还有人数、进场、点赞、分享等按期和不按期发送的不少种类系统消息。
若是假设每秒峰值有100条各种消息，100W*100=1亿，简单按单实例5Wqps算，须要2000个实例才能支持，虽然比老的群聊系统应该好不少，但系统仍是遇到大量资源冗余或应对峰值须要大量扩容的老问题。是否能有更好的解决方式？

2.4.7.1 延时聚合

这里咱们考虑常见的一个优化思路，是经过批量聚合的模式来提升系统性能。若是将这100条消息，每秒聚合打包一次来统一下发，QPS仍是100W，长链接系统的下发QPS不变，但每秒下发消息量级能够达到1亿，这个聚合方案实测是可行的。聚合模式，咱们付出的成本是消息时延的上升，1秒的聚合平均时延增长500ms，用户体验损失不算大，但系统下发消息量级能够提高百倍，综合评估成本收益来看是合理的。考虑到直播的实际场景，大多数场景下秒级的聚合和时延是能够接受的。
2.4.8 消息带宽问题
聚合延时下发，长链接单实例QPS问题解决了，随之而来的是，长链接单实例下发的带宽压力问题。例如，长链接单实例须要下发10000长链接时，每秒100消息，消息平均2K字节，实际带宽为2K*100*10000*8=15625Mbps，这已经超过单物理机的万兆网卡的带宽容量。
另外一方面，从全局带宽来看，也高达1.5Tbps，带宽资源对于机房出口也会带来压力，这样的带宽成本太高，须要削减带宽使用或有更好的替代方案。

• 压缩

面对下发数据量带宽消耗过大的问题，在不改动业务数据的前提下，咱们采用了数据压缩的解决方案。而压缩是CPU密集型的操做，因为直播业务的实时性，不能简单考虑压缩比，在综合平衡压缩比、压缩时延和压缩CPU消耗后，调优压缩库后实测的平均压缩比达到6.7 : 1，数据量压缩到原来的15%左右，这样15625Mbps*15%=2344Mbps=2.29Gbps；单机万兆网卡的带宽容量，最多承载4.27万的长链接下发，虽然没有达到5万，基本也能够接受。
从全局带宽来看，峰值也削减到不超过230Gbps，收益很明显。

带宽对比	压缩前	压缩后
单机10000长链接	15.26 Gbps	2.29 Gbps
全局100万长链接	1.49 Tbps	229 Gbps
全局500万长链接	7.45 Tbps	1.12 Tbps

2.4.9 客户端性能问题
进一步考虑，直播场景下，不只是有较高的峰值消息量级，而是在直播过程当中有持续的高消息量级压力；这不只对于服务端是压力，对于客户端来讲也是个挑战。持续的高消息量级，一方面，客户端在接收、展现等方面有明显的压力；另外一方面，直播界面上过多过快的消息刷新，对于用户体验也是有害无益的。

• 限速

因此，在综合平衡用户体验和客户端性能的基础上，消息服务端增长告终合消息优先级的分级频控限速机制，单用户客户端并不须要承受每秒100条的压力，削减每秒下发消息后，长链接单实例每秒下发5-8万长链接，CPU和带宽都是能够稳定支持的。
2.4.10 实时消息问题

• 优先级

咱们提供了基于消息优先级的实时下发机制，对于高优消息能够当即触发聚合下发，不会增长聚合延时；而对于普通中低优消息，仍是作延时聚合下发。
2.4.11 用户在线问题
组播mcast机制的出发点，在百万量级高并发在线的场景下，保障在线用户的消息到达，容许不在线用户接收消息的部分折损，付出合理的技术复杂度和成本，取得服务质量和性能平衡。
而针对在线用户的消息到达，还有个关键问题是如何保障用户的长链接在线。
为了提高长链接服务的接入稳定性和可达性，咱们在如下几个方面作了优化。

• 访问点

长链接服务在国内三大运营商的华北华东华南区域均部署了接入点入口；针对有部分国外用户的直播场景，增长了香港机房的独立接入点入口。

• HTTPDNS

针对部分用户的DNS劫持问题和解析错误问题，消息SDK接入了HTTPDNS服务并优化本地缓存，造成多级域名解析保障体系，提高了域名解析的可靠性，减小了DNS劫持和错误率。

• 心跳优化

长链接的心跳是保活探活的重要手段，针对直播场景实时性高的特色，为了尽快发现长链接断链，在组播mcastJoin后，长链接心跳也调整为间隔更短、服务端动态可控的智能心跳。这样在及时发现链接异常后，消息SDK能够快速主动从新建连。

• 断链恢复

在直播间用户已加入组播mcast的状况下，若是长链接断链，长链接服务端会主动或被动的触发清除组播mcast成员。而长链接重建连恢复时，直播业务层也须要监听链接恢复信号，从新加入组播mcast，以恢复组播mcast的消息通路。
2.4.12 组播mcast小结
综上所述，组播mcast机制，有效的解决了百万量级同时在线用户的消息实时下发问题；对于短时断链和消息过多，容许部分消息的丢弃；知足了直播场景消息的设计目标。
组播mcast机制特色是：

1. 消息服务和路由层压力较轻，总体压力只由长链接层承载，易于水平扩容。
2. 基于延时聚合下发，辅以压缩限速，能够很好的解决下行QPS与带宽的性能问题。
3. 系统总体下行的QPS和带宽是彻底可控的。100W在线用户的下行最大QPS是100W，500W在线用户的下行最大QPS是500W。单实例的下发能力5-8万QPS是稳定的。所以，能够很容易判断总体的系统容量，特殊场景是否须要扩容。
4. mcast机制虽然是针对直播场景提出的，但自己设计具备通用性，能够应用于其余须要实时在线大量用户分组的消息推送场景。

3、直播消息2.0 - 持续发展
在组播mcast机制解决了百万量级的在线用户实时消息下发后，直播消息的场景不断扩大，不断有直播创新业务提出新的消息需求。相应的，组播mcast的服务机制也须要与时俱进，不断在深度和广度上拓展优化。如下重点介绍一下历史消息和礼物消息。

3.1 历史消息
对于刚进入直播间的用户来讲，须要看到一些最近的聊天记录，以加强聊天互动氛围并帮助了解直播的进展；对历史聊天记录感兴趣额用户，还能够追溯更多的消息历史。这就产生了聊天历史的需求。
为了支持这类历史消息的需求，解决方案是对于每一个组播mcast申请开通一个组播公共消息信箱mcast-mbox服务。

1. 对于用户消息和其余有持久化须要的消息，所有写入这个消息信箱。
2. 用户能够指定组播mcastID，按时间区间和要拉取得消息条数，来获取组播mcast的历史消息。

补充说明一下消息信息的概念和应用。
3.1.1 消息信箱服务概念

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模型的相关信息。

3.2 礼物消息
△图4：礼物消息
礼物消息场景分析：

1. 用户送礼给主播，主播侧须要尽快、可靠地收到礼物消息通知，才能及时的给予用户反馈。
2. 送出礼物的用户，本地就可及时展现礼物效果，无消息通知强诉求。
3. 直播间内其余用户，须要收到礼物消息，以展现礼物效果，提高直播间互动氛围，激发其余用户送礼。
4. 礼物消息涉及用户订单和购买行为，须要由服务端确认发出。
5. 礼物消息优先级明显高于其余聊天消息、系统消息。

 基于以上分析，直播消息提出如下技术方案：

1. 增长一个独立的可靠消息组播mcast通道（如图4中组播mcast-2），专供高优可靠消息的收发；与其余普通消息、系统消息在数据流层面隔离，减小相互干扰；
2. 对于普通用户侧的端消息SDK，礼物消息组播mcast通道虽然是新增独立通道，消息收发逻辑与普通消息组播mcast通道保持一致；
3. 对于主播侧，端消息SDK对于礼物消息组播mcast通道，须要支持推拉结合模式，以保障礼物消息的所有到达；即便有短暂的掉线，也须要取到所有礼物消息；
4. 对于主播侧，在极端状况下，若是长链接建连有异常，消息SDK能够经过短链接接口轮询，来拉取礼物组播mcast信箱消息来兜底。

基于以上独立的可靠消息组播mcast通道方案，在未剔除一些异常场景的状况下，如主播下线未关播、数据偶发打点丢失等，礼物消息的触达率已达到99.9%以上。

3.3 直播消息其余方面的发展
在百度直播的发展历程中，直播消息服务还面临着许多其余基础性问题和创新业务带来的其余挑战。如今这些问题都有了较好的解决方案，如下列举一些，供你们学习参考：

1. 如何支持多种客户端场景，安卓、iOS、H五、小程序、PC。
2. 如何支持同一场直播的消息在百度APP和好看、全民、贴吧等矩阵APP的打通。
3. 如何支持非登陆用户。IM通常是支持登陆用户，而直播场景也须要支持非登陆用户。
4. 长链接服务若是出了严重问题，是否有端获取消息的降级通道。
5. 直播消息审核的机审人审如何作，如何支持先发后审和先审后发。
6. 如何支持跨多个直播间的消息。
7. 直播消息服务是如何支持创新业务的，如答题直播、直播带货、直播连麦等。

限于篇幅，以上问题在此再也不作具体讨论，有兴趣同窗欢迎直接联系探讨。

4、回顾展望
自百度直播上线以来几年间，直播消息服务迎难而上，一路披荆斩棘为百度直播保驾护航，为百度直播提供了坚实的技术支撑和保障。
将来，在支持直播创新业务、更细粒度的消息分级服务、直播消息基础服务的稳定性和性能等方面，直播消息服务会继续努力，夯实基础，持续创新，以支持直播业务更好更快的发展。

推荐阅读
｜万象：百度的海量多媒体信息处理系统

----------  END  ----------

百度架构师

百度官方技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢迎各位同窗关注！