消息平台在直播场景中承载着播控业务（开停播、智能档）、互动业务（聊天、打赏、红包雨），并广泛应用于直播内容对齐场景，是直播内容生产和消费的重要一环。

但是在大规模在线直播场景下，随着在线用户规模攀升，传统 “ 推模型 ” 会导致消息成本居高不下。而为了降成本所采用的时间换空间的合包、分批下行策略，又难以保证消息的下发性能。如何让成本与效率兼得？ 本文整理自阿里文娱技术专家赵光男在InfoQ技术公开课的分享，主要以双11猫晚直播为例，详解在百万级直播场景下，优酷如何利用 “ 拉模型 ” 保证消息平台的低成本、高性能、高可用。

本次分享主要围绕以下五部分展开：

超级直播场景下消息平台的挑战
整体介绍优酷消息平台，包括平台能力和端到端的架构
重点介绍消息推拉链路实践，包括推模式设备分桶、链路去中心化、合包分批
针对超级直播，拉模式如何兼顾性能和成本
个人的技术思考

大家都知道，每年的双11和猫晚，对阿里技术同学来说都是一次大练兵，不仅要扛住瞬时的高并发，还要高清不卡顿，更要让观众边看边买，秒开秒买。这其中直播消息起到至关重要的作用，比如主持人在台上说，倒计时5秒抢红包雨，消息下发就要实现线上线下数千万人的秒级一致。如果早1秒，红包雨还没开始，如果晚1秒，红包雨就快结束了。

双11猫晚无论是在线规模、互动玩法、覆盖国家和地区，还是节目的复杂度，都是行业TOP级的超级直播。从消息平台的角度出发，我们面临3个挑战：

性能：百万用户同时在线实时互动，下行要高吞吐，要低延迟（支持内容对齐场景）；
成本：在线规模持续攀升，但带宽、机器成本要降低；
稳定性：端众多（OTT/PC端/移动端），端侧性能差异大，需要保证端到端0故障。

如何化解这些挑战？我们需要从直播规模的角度切入并匹配不同的技术策略。从经验出发，我们将直播划分为三大类：

第一类是日常的小型直播，比如秀场类，会利用实时推送通道；
第二类是在线规模大，且消息频度高、实时性要求高，比如双11猫晚，我们会选择短轮询通道，提升性能，降低成本；
第三轮是在线规模大，但是消息频度底，对实时性要求也不高，比如点播页直播，我们会采用合包、分批的策略，降低成本。

从整体看，消息平台在整个直播链路中的位置，向上承接流的分发，向左连接互动组件，向右连接互动生产，是直播内容生产与消费的关键一环。

直播业务分为生产和消费两部分。内容生产包括两部分，第一是直播流的生产、流的分发和流的消费，在流的分发中也会有一些播控消息，通过消息通道触达到端上；第二是互动生产，包括一些用户的互动，像聊天、送礼、点赞，还有运营主动触发的互动，主动投放的活动像投票、图文、红包雨，也是通过消息通道，然后触达到端上的互动组件，这是消息通道在优酷直播业务里的位置。

上图是整个直播消息平台的能力模型。用户消息平台支持不同的业务方接入，为此提供了一套标准化的客户端服务端接口和消息协议；在统计指标上建立了包括建联成功率、实时到达率、消息延迟等核心指标的统计；流控方面做了单播和广播限流，日常直播采用实时推送通道，超级直播采用短轮询通道。下行能力包括用户和设备单播、频道广播，消息服务的保障上提供了完善的消息应急预案和监控预警。

消息平台的端到端架构主要分三部分：消息服务端的SDK、消息服务、消息客户端。

用户进入直播间，首先通过消息客户端SDK的建立控制模块打开通道，通道打开成功之后，会启动相应的自检，包括心跳和通道的保活。接下来，启动一些统计模块，包括前面提到的建联成功率、到达率、消息到达率。对应的服务端也有，包括分端的建联控制和建联黑名单。服务端核心的监控指标包括设备在线到达率和延迟，链路探测的保活模块。

业务消息通过消息服务端的SDK经过hash路由进入消息服务，消息服务通过流控模块，途经消息处理模块，包括下消息的消息合包和定频下发，找到对应的通道模块。日常直播下会采用实时推送通道去触达端上。如果是百万级的超大型的直播场景，则通过短轮询通道分发到端上。

端上SDK也分为实时推送和短轮询通道两部分。实时推送包括native的实时通道、h5的实时通道，以及应对超大型直播的短轮询通道。到达端上的通道模块之后，消息会经过过期、去重通过分发处理模块，最终给到业务侧。

以上是优酷消息平台端到端的架构和数据处理流程。

下面介绍消息推拉链路的实践。日常的直播场景可能是几十万级用户同时在线这样一个规模，为了承接大量的在线、提升下行的分发效率，我们通常采用设备的Hash分桶下推策略。重点考虑下面两点：

负载均衡：大部分Hash算法保证均匀的负载分配，但是还要考虑部分机器失效后有状态负载迁移的问题（比如：同一分桶设备消息批量推送）；
平滑失效转移：消息扩散层SDK通过固定分桶配置计算哪台机器应该推送分桶索引列表，RPC调用某台扩散层机器时，将分桶索引列表携带到消息对象中实现消息级平滑切换。

消息分发吞吐提升也伴随着推送成本急剧增加，为了降低消息扩散成本，需要尽量简化链路调用。可以通过设备连接层保存设备和连接绑定关系，提供设备单播能力的中心化集群。去中心化则可以减少设备连接层IO次数，并且可以合并接入层调用。

应对双11这种超级直播场景，为何选择拉模型去分发消息？推模型的分发成本中，第一个因子是下行QPS，第二个因子是在线设备数据。QPS越大、在线设备数越高，分发成本也越高。

为了减轻整个下行的扩散成本，可以固定整个下行的QPS。如，通过固定时间合包的方式，将下行QPS变成一个定值，同时对在线设备进行分批的操作，去减少下行的扩散规模。比如A消息、B消息、C消息，在同一个合包间隔把三个消息打成一个大消息包，进行压缩编码，投递到下行的的消息扩散层，消息扩散层也会在同一台机器上进行扩散，比如说第一批推设备123，然后第二批推设备456，第三批推设备789。这样相当于将下行的扩散压力分类减少了1/3，但这样带来的问题是有固定的合包间隔，并且下行的设备分批，就会导致消息的延迟变大，没法满足大型直播的内容对齐场景需求。

基于以上两点，在选型中选择了消息拉链路。在保证一定性能的前提下，大幅度降低了成本。

消息推成本包含两部分：第一部分（下行QPS * 在线规模）/单机能力就是机器的部署规模，第二部分成本是 BGP 带宽的成本。如果选型短轮询CDN则成本只有带宽成本，没有应用服务器的部署成本， CDN 带宽价格成本大约是BGP带宽成本的1/66 。

业务消息下发的时候，根据直播间维度进行消息打包，每个直播间有一个CDN地址。可以动态配置拉取间隔和重投策略，包括重投次数和重投间隔。客户端SDK通过对应的直播间CDN地址拉到广播消息，拉取的时候也通过etag缓存去过滤一些没必要的请求。

消息拉模式在延迟和成本上相对于推成本降低了很多。拉链路难解决的问题是如何统计拉链路的消息到达率。设备进直播间之后，设备和直播间的绑定关系在端上，所以消息到达率也应该在端侧统计。

到达率的统计包括两部分：第一部分是实时的到达率统计，实时关注整体服务情况；第二部分是真实消息的到达情况，通过离线的计算方式去统计。

为什么通过离线的计算方式？因为在规模较大的情况下，统计链路的压力比较大。比如100万在线，为了统计某一条消息的到达率情况，需要处理100万QPS的上行请求。最终我们对应的策略是选择客户端的一个监控汇报链路，并且在消息侧和设备测都做了采样，通过消息的批量ACK 来减轻服务端的统计压力。

我们不只要保证服务端的稳定性，也要保证客户端稳定性。具体做法是，消息下行管控层SDK后，通过一致性Hash去调用某台机器，做精细化的限流Hash。比如，可限制某个直播间的某一个消息类型的下行QPS ，保证每个业务类型到达端上的流量，不大于业务最大处理能力，兼容低端设备的消息处理性能。

像双11 猫晚这类大规模在线场景，直播前需要做非常多的准备工作，包括直播容量的评估、服务扩容、监控大盘的配置、防刷和限流的配置等。最重要的一点，大型直播一定要准备降级预案，同时要进行业务场景的压测，包含建连的压测、接口的压测，在业务引流场景下的一些模拟的压测，下行的压测和端侧的压测。

最后，从我的技术经验出发，分享一些个人思考。如果屏幕前的你，也在着手做直播项目，那么从最基础的稳定性上，请重点关注三件事：

关注流控：流控非常重要，将每一个流程细化，并逐项做拆解，来保证服务水位和客户端稳定性；
关注压测：场景压测，尤其是导流策略、运营互动策略；
完善预案：多套完善的预案，包括降级预案、用户建连预案、消息下行预案，并且让合作方都清晰的知晓，都讨论演练过。

从平台建设角度，有两点建议：

技术策略要灵活，针对不同业务场景，要选择适合的技术。一定多思考，在技术实践中做提炼，因为我们面对的很多业务是没有借鉴的，怎么组合怎么选项，需要自己去发现；
对于业务的上下游，要时刻保持“警惕”，向上要做好资源管控隔离，向下要有容错降级的方案。既信任你的队友，也要有全盘思考。

更多实践细节，可以参考 InfoQ 公开课的完整视频回放：

https://www.infoq.cn/video/w5jYq4ZaP6UfVtwXZays

作者介绍：

赵光男，阿里文娱技术专家，现负责阿里文娱消息平台建设工作，在应对大规模在线场景有深入技术积累，曾负责2018年世界杯千万级在线直播服务稳定性、2019年双11猫晚直播消息服务等，目前正持续构建低成本、高性能、高可用消息平台。

创作场景

优酷直播消息平台建设和双 11 猫晚高可用实践