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

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

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

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

1. 超级直播场景下消息平台的挑战

2. 整体介绍优酷消息平台，包括平台能力和端到端的架构

3. 重点介绍消息推拉链路实践，包括推模式设备分桶、链路去中心化、合包分批

4. 针对超级直播，拉模式如何兼顾性能和成本

5. 个人的技术思考

大家都知道，每年的双 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 猫晚直播消息服务等，目前正持续构建低成本、高性能、高可用消息平台。