本文原题“百度直播消息服务架构实践”，由百度APP消息中台团队原创分享于“百度Geek说”公众号，为了让文章内容更通俗易懂，本次已做排版优化和内容重新划分，原文链接在文末。
一套完整的直播系统核心功能有两个：
本文主要分享的是百度直播的消息系统的架构设计实践和演进过程。
实际上：直播间内用户的聊天互动，虽然形式上是常见的IM聊天消息流，但直播消息流不仅仅是用户聊天。
除用户聊天外：直播间内常见的用户送礼物、进场、点赞、去购买、主播推荐商品、申请连麦等互动行为的实时提醒，也是通过消息流下发的。
此外：直播间关闭、直播流切换等特殊场景，也依赖消息流的实时下发。
所以，直播系统内的消息流可以认为是直播间内主播与用户间实时互动和直播间实时控制的基础能力，也是系统支撑。如果说实时音视频推拉流是直播系统的灵魂，那消息流可以说是直播系统的骨架，它的重要性不言而喻。
那么，如何构建直播的消息系统，又有哪些挑战需要解决，借着本文我们一起来梳理一下。
学习交流：
- 即时通讯/推送技术开发交流5群：215477170 [推荐]
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK
（本文同步发布于：http://www.52im.net/thread-3515-1-1.html）
本文是系列文章中的第4篇：
《直播系统聊天技术(一)：百万在线的美拍直播弹幕系统的实时推送技术实践之路》
《直播系统聊天技术(二)：阿里电商IM消息平台，在群聊、直播场景下的技术实践》
《直播系统聊天技术(三)：微信直播聊天室单房间1500万在线的消息架构演进之路》
《直播系统聊天技术(四)：百度直播的海量用户实时消息系统架构演进实践》（* 本文）
直播间内的聊天消息，经常被类比于普通的IM群聊功能。
群聊是大家比较熟悉的即时通讯（IM）场景，直播间内聊天和群聊，二者有相似性，但也有本质的区别。
对比二者的特点，直播消息与IM群聊主要有以下区别：
1）参与人数不同：IM群聊的参与人数上千人就是很大的群了。但对于高热度的大型直播场景，例如国庆、阅兵、春晚等，单直播间累计用户是百万甚至千万量级的集合，同时在线人数可达数百万人。
2）组织关系不同：IM用户进群退群，是相对低频的操作，用户集合相对固定，用户进出的变更频度不会特别高。而用户进出直播间，是非常频繁的，高热度直播的单直播间每秒面临上万用户的进出变更。
3）持续时间不同：IM群聊建立后，聊天持续时间可能比较长，几天到数月都有。而直播间大部分持续不超过几个小时。
根据上节中，直播消息和IM通聊的类比分析，针对直播中的消息系统，我们可以提炼出两个核心技术挑战。
挑战一：直播间内用户的维护
支持在线百万、累积千万两个集合，每秒4万QPS更新，有一定压力，但有支持高读写性能的存储应该可以解决，例如redis。
挑战二：百万在线用户的消息下发
面对百万在线用户，上下行都有大量的消息，从直播用户端视角分析：
由于技术挑战一不难解决，以下内容主要讨论技术挑战二。
综合考虑上节的技术挑战和直播业务场景，我们对于消息系统的需求目标有比较明显的指标定义。
技术设计目标定义大致如下：
现在：问题的核心是，如何做到把不超过N条的消息，在S秒内，下发到直播间内的百万用户（假设 N<=20，S<=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对服务端的压力。
显然：完全重用群聊的消息流程，对消息服务和长连接服务带来的压力是巨大的。
IM群聊数据流优化后的压力点：
如上图所示，现在我们来分析以上每个百万量级的挑战，是否有优化的空间：
如上优化后，减少了②⑤⑥三个百万量级压力请求，但还有①拆分用户列表③动态路由查询④长连接下发，这三个百万量级步骤需要处理。
对于①拆分用户列表：支持百万量级用户列表查询，比较常规的思路是支持基于群groupID的批量查询，例如一次可以查出100个用户，1万QPS查询就可以支持到百万；基于群groupID把用户数据的存储，分散到多个主从实例和分片上，控制好打散粒度不出现热点，基本能做到，只是存储资源可能消耗较多。
对于③动态路由查询：表面上看，面临的问题与①类似，但却有些不同。因为群的用户列表，是基于群groupID做key，建立一个表或多个打散的表；而device-i-j的查询是完全分散的，也是需要批量查询能力，但是完全分散的设备信息查询，不能只针对特定key做优化，需要动态路由服务支持整体上达到百万QPS的查询性能。
对于④长连接服务下发：由于长连接服务不依赖外部的存储服务，如果整体要支持百万量级的下发能力，若长连接单实例能支持1万的下发能力，整体上100个实例就能支持到百万量级下发。
基于以上分析：支持百万量级的消息下发，初见曙光。似乎只要优化好用户列表、动态路由的存储/查询和长连接的容量扩容，但所有的前提是需要消耗大量存储和机器资源。
考虑到直播业务的实际情况，现实不容乐观：
而实际上：在线用户峰值量级很难估计准确，这样会造成实际资源利用率很低，扩缩容的操作频繁，运维成本高。是否选择这个方案，也是很令人纠结。
也有人提过拆分多个群组的方案。
例如：如果一个群组最多支持1万用户，开100个群就可以支持一百万用户；再建立一个虚拟群，将这100个群关联起来，似乎可行。
但如果仔细分析，会发现以上提到的几个问题：“①拆分用户列表、③动态路由查询、④长连接下发”，高压力依然存在，还是不可避免。
除此之外，多群组还会引入其他问题：
基于以上分析，我们并没有选择多群组方案。
经过上节中类比普通IM群聊消息的架构设计，本节将介绍我们支持实时高并发百万量级同时在线用户的直播消息架构——组播mcast方案的提出及演化。
是否要采用上节基于IM群聊的优化方案，还是可以另辟蹊径？
先暂时抛开群收发消息流程：对于消息下发来说，如果一定要说一个步骤是必不可少的，那一定是长连接下发这步了。没有通过长连接下发，消息就无法最终到达用户。
当然有人说轮询拉取也可以替代长连接下发，来获取消息，但显然轮询拉取的性能压力和实时性与长连接下发相比差很多，故不在讨论范围。
如果能简化为：给长连接服务下发消息时指定一个类似的groupID，长连接服务能直接拆分到所有群组用户相关的长连接connect-j，就可以省略掉用户列表拆分和动态路由查询的百万量级查询。
这样的话：消息下发的压力将主要由长连接服务来承受，服务端也不需要对多个系统扩容，直播消息的优化可能会大为简化。
根据这个思路：相当于在长连接服务中，对连接connect也建立群组的概念。基于连接组的设想，我们设计了一套长连接的组播mcast机制。
基本概念总结如下：
组播mcast-m的路由route-m，是一个长连接服务实例的集合LcsList，记录了所有加入mcast-m的长连接connect-i所在长连接服务实例lcs-j。
加入组播mcast的逻辑流程：
离开组播mcast，与加入组播mcast基本类似，由客户端调用消息sdk离开mcast-m，发出上行请求mcastLeave（mcast-m），长连接服务端更新路由和mcastConnectList-m信息。
组播mcast数据流及压力点：
基于组播mcast的长连接消息推送过程，是一个 1:M * 1:N 的扩散放大过程。
具体过程描述如下：
现在分析一下以上的组播mcast机制的性能压力：
综上可知：对于100Wqps的下发，20个长连接实例就可以完全负荷(20*5W=100W)，且有一定裕量。如果500Wqps的下发，也不超过100实例；1000W的下发，如果以8W单实例较大的负荷承载，125实例就可以支持。
看上去，基于以上组播mcast机制，我们建立了一套高效的支持百万量级QPS的长连接下发机制，当前长连接服务的容量就可以支持，基本不用扩容。但是否能完全满足直播业务场景需求，还需要进一步讨论。
对于每秒1条消息，扩散到100W用户，甚至500W用户，以上组播mcast机制似乎都能应对。
但直播间内消息的实际情况是：热门的直播每秒用户上行聊天消息会有很多，除聊天消息外，直播间还有人数、进场、点赞、分享等定期和不定期发送的很多种类系统消息。
如果假设每秒峰值有100条各类消息：100W*100=1亿，简单按单实例5Wqps算，需要2000个实例才能支持，虽然比老的群聊系统应该好很多，但系统还是遇到大量资源冗余或应对峰值需要大量扩容的老问题。是否能有更好的解决方式？
这里我们考虑常见的一个优化思路，是通过批量聚合的模式来提高系统性能。
如果将这100条消息每秒聚合打包一次来统一下发，QPS还是100W，长连接系统的下发QPS不变，但每秒下发消息量级可以达到1亿，这个聚合方案实测是可行的。
聚合模式，我们付出的成本是消息时延的上升，1秒的聚合平均时延增加500ms，用户体验损失不算大，但系统下发消息量级可以提升百倍，综合评估成本收益来看是合理的。考虑到直播的实际场景，大多数场景下秒级的聚合和时延是可以接受的。
如上节所分析的，聚合延时下发，长连接单实例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，收益很明显。
进一步考虑，直播场景下，不仅是有较高的峰值消息量级，而是在直播过程中有持续的高消息量级压力。这不仅对于服务端是压力，对于客户端来说也是个挑战。
持续的高消息量级：
所以：在综合平衡用户体验和客户端性能的基础上，消息服务端增加了结合消息优先级的分级频控限速机制，单用户客户端并不需要承受每秒100条的压力，削减每秒下发消息后，长连接单实例每秒下发5-8万长连接，CPU和带宽都是可以稳定支持的。
我们提供了基于消息优先级的实时下发机制：
组播mcast机制的出发点，在百万量级高并发在线的场景下，保障在线用户的消息到达，允许不在线用户接收消息的部分折损，付出合理的技术复杂度和成本，取得服务质量和性能平衡。
而针对在线用户的消息到达，还有个关键问题是如何保障用户的长连接在线。
为了提升长连接服务的接入稳定性和可达性，我们在以下几个方面做了优化。
1）访问点：
长连接服务在国内三大运营商的华北华东华南区域均部署了接入点入口。针对有部分国外用户的直播场景，还增加了香港机房的独立接入点入口。
2）HTTPDNS：
针对部分用户的DNS劫持问题和解析错误问题，消息SDK接入了HTTPDNS服务并优化本地缓存，形成多级域名解析保障体系，提升了域名解析的可靠性，减少了DNS劫持和错误率（见《百度APP移动端网络深度优化实践分享(一)：DNS优化篇》）。
3）心跳优化：
长连接的心跳是保活探活的重要手段，针对直播场景实时性高的特点，为了尽快发现长连接断链，在组播mcastJoin后，长连接心跳也调整为间隔更短、服务端动态可控的智能心跳。
这样在及时发现连接异常后，消息SDK可以快速主动重新建连。
4）断链恢复：
在直播间用户已加入组播mcast的情况下，如果长连接断链，长连接服务端会主动或被动的触发清除组播mcast成员。
而长连接重建连恢复时，直播业务层也需要监听连接恢复信号，重新加入组播mcast，以恢复组播mcast的消息通路。
综上所述，组播mcast机制：
组播mcast机制特点是：
在组播mcast机制解决了百万量级的在线用户实时消息下发后，直播消息的场景不断扩大，不断有直播创新业务提出新的消息需求。
相应的，组播mcast的服务机制也需要与时俱进，不断在深度和广度上拓展优化。以下重点介绍一下历史消息和礼物消息。
对于刚进入直播间的用户来说，需要看到一些最近的聊天记录，以增强聊天互动氛围并帮助了解直播的进展；对历史聊天记录感兴趣额用户，还可以追溯更多的消息历史。这就产生了聊天历史的需求。
为了支持这类历史消息的需求，拓展方案是对于每个组播mcast申请开通一个组播公共消息信箱mcast-mbox服务。
逻辑是这样的：
下面补充说明一下消息信息的概念和应用。
什么是消息信箱服务的概念？
实际上，最常用的就是基于msgid范围的消息拉取。这里的消息信箱服务是时间线timeline模型，有兴趣的同学可以进一步参考时间线timeline模型的相关信息（见《现代IM系统中聊天消息的同步和存储方案探讨》一文中的“4、Timeline模型”一节）。
礼物消息：
礼物消息场景分析：
基于以上分析，直播消息提出以下技术拓展方案：
基于以上独立的可靠消息组播mcast通道方案，在未剔除一些异常场景的情况下，如主播下线未关播、数据偶发打点丢失等，礼物消息的触达率已达到99.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) [附件下载]》
本文已同步发布于“即时通讯技术圈”公众号。