春晚直播稳定性保障实践

每年的央视春晚直播，是对爱奇艺直播链路上所有技术团队的一次大考。央视春晚除了会引起服务接口QPS的暴涨，也会对CDN带宽和核心机房带宽带来瞬间的压力。此外，直播对线上故障处理时间的要求特别高，因此直播链路上的各个环节都要做好充分的高可用性保障。

整个直播链路，大致可以分为信号编码与切片处理、CDN分发与回源、节目播放请求处理、视频切片下载与播放四个环节。本文分别介绍这四个环节在2024央视春晚中的稳定性保障实践工作。

 01 

信息编码与切片处理

直播云作为直播核心技术支持，负责直播编码、RTMP传输、切片打包以及切片上传，这一连串的技术流程确保了直播内容的流畅、清晰与稳定；为跨年及春晚系列直播的技术保障与呈现提供高质量的画质和稳定可靠的信源。

作为影响画质的首要因素，此次春晚系列直播编码环节进行了全面升级。我们不仅支持HDR（高动态范围）信源输入，还成功生产出HDR运营流，使得色彩层次更加丰富，对比度与亮度范围显著拓宽，为观众带来了前所未有的视觉盛宴。此外，通过对HDR信号进行智能转码生成SDR（标准动态范围）运营流，即便是不具备HDR播放条件的设备也能享受到远超以往的画质提升。更值得一提的是，引入4K超高清实时编码能力，保证了终端显示的每一帧都细腻逼真，借助帧绮映画技术，让春晚的每一个细节生动展现。

在保障直播稳定性方面，我们深知直播编码信源的稳定性对直播效果至关重要。因此，我们采用了一主四备共五个信源的方式，以确保信源的稳定可靠。这五路信源分别是：两路卫星信号，通过Anystream技术转码为4K HDR PQ和SDR格式；两路CCTV 4K网络信号，提供HDR HLG格式，并实时转换为PQ和SDR格式；以及一路来自演播室的CCTV1高清信号与网络CCTV 4K信号。这种多元化的信源配置，有效避免了因单一信源故障导致的直播中断问题。

最终，在春晚直播的实际呈现中，我们取得了显著的成果。央视春晚首次在TV端呈现了4K帧绮映画MAX，为观众带来了前所未有的视觉盛宴。而在央视元宵晚会上，我们更是首次在多个前端同时呈现了4K帧绮映画以及1080p50高帧率内容，让观众在享受高清画质的同时，也能感受到高帧率带来的流畅体验。在质检评测中，我们的直播技术在静态画面清晰度上位列第一梯队，充分展示了我们的技术实力。而在舞台灯光效果复杂的场景中，爱奇艺的动态效果表现稳定，与竞争对手相比具有明显优势；春晚系列直播全程编码稳定无任何信源异常，为流畅稳定的直播体验提供了坚实基础。

 02

CDN分发与回源

内容分发网络（Content Delivery Network, CDN）作为超大规模的分布式系统，已经成为互联网的基础设施，在内容动态加速，静态加速以及安全防护方面发挥重要作用。CDN的直播分发，可以理解成一棵树，直播流就是树的养分，养分从树根流向叶子，CDN做的事情就是保障树的养分快速分发到所有的叶子。在春晚直播项目中，CDN的主任务就是将直播分片，快速、稳定的分发到边缘节点，供用户播放使用。

下图是CDN分发回源架构图，我们将L1、L2、PROXY这3层称为直播源站，即根节点。将商业CDN、COC（Cache On Cloud）、自建CDN称为边缘节点，即叶子节点。

在CDN的整个分发体系中，直播源站的稳定性是重中之重，如果直播源站出现问题，会导致全网播放卡顿、播放失败，所以保障直播源站的高可用，一直是直播CDN的工作重心。

源站可用性保护（Origin Shield）

源站高可用

高可用由多层次组成：

直播源站软件

软件组成的服务/节点

服务/节点组成的集群

各个集群组成的整体源站

服务/节点和集群依赖的网络

针对直播软件ATS（Apache Traffic Server），通过线上卡顿分析定位，故障分析，解决了一些关键性问题，比如edns模块导致的5XX不服务问题，以及长时间运行时导致回源内存泄露问题。

在源站L1、L2、PROXY各层中，均是多机房部署，避免单点故障。当遇到节点故障时，需要做到故障节点自动摘除，无需人工参与。同时准备好各机房内网专线的灾备能力、冗余带宽，确保不在内网回源上产生瓶颈。

针对商业CDN供应商，提供域名形式的源站，源站域名每个地区均不少于4个源站PROXY，且源站的TTL由默认的600s降低为120s，结合拨测+主备替换能力，可以在小于2分钟内自动替换故障源站，减少源站故障时对商业CDN回源的影响。

COC作为CDN上云的Cache集群，通过专线连到源站Proxy进行回源，因为COC会承载直播流量高，除了对此专线特别保障外，还在龙年春晚前，通过云上SNAT，建立了COC的公网备用回源链路，并且在春晚时启用这条链路，提高COC回源的容错性。

CDN供应商回源隔离

作为multi-CDN的直播架构，面对春晚大型直播，为了避免某一商业CDN厂商故障导致影响源站，进而影响其他CDN供应商的服务，演变成全局故障，我们对源站资源进行分组隔离，分成多组回源域名，并且对带宽占比高的厂商，或者在平常直播中易出问题的厂商，分配单独源站，与其他回源源站代理隔离。

源站限流

当某个厂商真的出现故障时，不可避免的会出现大量回源请求，源站的承载能力是有限的，所以限流必不可少。

春晚前，根据不同文件消耗的带宽、IO频次、大小文件比例等，进行直播源站压测，在不同读写模型下，限流功能工作正常，符合限流预期。

因为不同的文件回源qps是不同的，所以我们还优化源站限流策略，分离小文件与视频文件的限流策略，避免小文件的请求突发影响到视频文件回源。

最后，在与每家商业CDN对接的过程中，我们还对源站响应头进行了优化，对商业CDN合并回源、过期缓存等行为更友好，降低供应商适配难度。

回源带宽准备

面对春晚大规模直播并发，除了准备大量的CDN带宽资源满足用户观看需求，还由此带来CDN回源风险，各家CDN回源采取的技术与策略不一样，对CDN源站来说请求就是动态变化的，常常出现不可预知的因素，所以源站带宽资源必须准备充足，以应对回源缓存踩踏突发。

春晚前，对源站代理Proxy进行了资源扩容，准备了几十台商业源站Proxy，扩大国内代理带宽储备以及海外代理带宽储备。除夕当晚的直播过程中，确实出现了某商业CDN突发的回源流量风暴冲击，团队根据事前准备方案采取了合适措施及时解决。

监控能力

由于直播的实时性要求，实时的监控能力，对源站监控特别重要，它能够帮助我们第一时间发现直播源站异常，并采取相应的止损措施，做到第一时间故障逃逸，避免故障范围扩大，引发雪崩。

春晚前，CDN团队将整个全部机房的边缘CDN节点的直播监控，由5-10分钟的监控延迟，降低至1分钟。这帮助我们在春晚过程中第一时间发现了2家商业CDN回源异常，并及时采取了相应措施，避免了批量故障。

故障演练

春晚前，我们对可能发生的源站故障进行了梳理，并制定源站故障预案手册，并且对每个case进行了故障演练。

在某些极端情况下，比如存储故障，虽然有L0进行兜底，但是保险起见还是会对异常节点进行下线，对诸如此类的场景，完成了故障切换演练。

商业CDN资源管理

春晚需求带宽量巨大，除了日常的CDN供应商外，我们还招募对接了一些临时的CDN厂商服务春晚直播。

无论是日常的CDN供应商还是临时供应商，面对春晚时都会调整资源来服务春晚，这些调整通常对CDN团队都是黑盒。为了保障各个供应商稳定服务春晚，需要对这些CDN资源进行功能与性能的评估。春晚直播过程中CDN上会同时存在多种类型的文件混合请求的情况，且请求QPS和带宽均比平常大，为了提前发现可能出现的问题以及校验新增扩容资源的可用性，我们按预估带宽和请求的数倍进行混合压测。

大流量压测

构造压测工具来模拟真实用户直播播放场景下的CDN访问流程，通过IPES FaaS函数计算中台，分运营商在多区域大量分散的部署压测工具，根据商业CDN容量上限来配置并行度后开启压测，监控线上带宽达峰情况。

相较于常规的大流量压测，压测工具额外还投递了m3u8索引文件和分片视频ts文件的如下信息：下载速度/缓存命中情况/DNS耗时/TCP握手耗时/首包耗时/首KB数据耗时，据此可以统计出压测期间的平均速度/高速占比/低速占比/各网络阶段平均耗时等统计信息，可以精确的和日常工况做比较来定位到更深层的问题。

小文件压测

春晚直播除了会造成大流量的视频ts文件请求之外，还存在很多类型的小文件请求，主要是校验文件和频繁更新的m3u8索引文件，其中m3u8文件会以1秒间隔持续更新内容以返回最新的视频ts文件列表，这些文件体积小占用带宽少，平常压测过程中比较容易忽视，但是因为访问量很大，出现问题时很容易将CDN缓存体系打穿导致线上大规模故障。

通过分析前期的大型直播数据得到直播中存在的各种文件类型及其请求占比，对每类都构造出压测请求，模拟出不同清晰度的直播码流请求，模拟http和https请求，并且囊括可能会出现的异常请求状况，以获取404触发回源时商业CDN的缓存穿透情况，在多区域大量分散的部署压测工具，根据预估用户量和商业CDN容量上限来配置并行度后开启压测。

统计压测过程中小文件请求返回的httpcode和返回内容的准确性，根据返回header中的Last-Modified计算文件更新延迟时间，统计小文件请求总访问耗时，统计实际压测总访问量和CDN服务器日志及其源站日志，计算出各种类型请求的回源比，并按域名和测试区域归类统计各类数据判断是否存在异常。

问题修复

构造压测结果统计报表体系，在压测后可以快速获取到各个维度的统计数据表格，方便排序定位异常极值，以及和现有商业CDN的日常工况做对比，在问题修复后再次进行压测可以方便的进行对比验证。

因直播业务流程相对于点播更为复杂，部分新对接的商业CDN理解并处理压测异常的进度较慢，特殊情况下需要配置网络探针来协助完全精确的定位到某区域某服务器的具体问题点，以协助商业CDN快速推进问题的解决。

这样春晚之前，对所有商业CDN厂商，分ISP进行共计54轮次压测，总计发现19个问题点，并全部推动修复达标，有效的保障了春晚直播CDN体系的稳定性。

直播P2P服务

鉴于春晚期间带宽需求量大，除了储备充足的CDN带宽外，还采用直播P2P技术。直播P2P不仅能显著降低运营成本，还能通过从边缘节点获取直播数据的方式，有效减轻CDN资源的负载，并显著提升直播流的获取速度。

直播Tracker服务部署

直播P2P调度服务，即Tracker服务，采用入口Tracker与工作Tracker相结合的部署策略。平常直播规模小，面对春晚，为确保直播tracker的高可用性，结合自建与公有云混合部署的方式，多地多机房来服务。

基于直播压测数据以及春晚规模预估，对直播Tracker大规模扩容。结合春晚期间直播带宽需求高，而其他业务带宽需求相对较低的特点，采用了直播tracker与其他业务物理机混跑的方式，并额外申请了公有云BEC资源用于部署直播Tracker，以确保系统具备足够的冗余和弹性，应对春晚突发流量。

直播Tracker压测

春晚直播期间，大量客户端将向Tracker发出请求，以期获取可用的P2P种子节点。Tracker服务的稳定性直接关系到直播的分享效率。因此，通过IPES平台部署了大量模拟直播客户端，模拟春晚直播场景下的请求流量，以此确定直播Tracker的服务上限，并评估其资源冗余是否足以应对春晚期间的大流量需求。

在压测过程中，密切监控机器负载数据，包括CPU、内存利用率，以及业务相关的P2P节点数、QPS等指标。结合过去春晚期间最高P2P节点数与压测中单台P2P节点的性能表现，用于预估直播Tracker的容量是否能满足春晚直播的需求。

直播P2P结果

若直播仅仅依赖用户间的节点上传，分享比不高。我们根据2023年春晚P2P效果，龙年春晚前准备了更多的闲置资源作为P2P节点来服务，特别是针对在移动CMNET网络，资源数量提升了60%。与客户端一起，最后P2P在春晚提供大量带宽，卸载了CDN的压力，并且在移动CMNET网络中分享比提升17pp。

 03

节目播放请求处理

---

直播中台

直播中台需要处理客户端的开播请求，并把直播节目相关的元数据返回给客户端。此外，直播中台也要考虑特效文件、表情文件等资源文件的并发请求问题。

每年央视春晚的正式节目，都是晚上八点开始。因此，在八点前后，后端接口的访问量会出现井喷，如下图。由于客户端进入直播间时，一般都会需要下载资源文件，可以想象到，如果不加干预，那么下载资源文件导致的带宽也会出现井喷。

后端****接口

容量准备

首先肯定是要保证后端服务能扛得住足够大的并发请求量。虽然八点前后的请求量会出现井喷，但观看央视春晚直播的爱奇艺用户量毕竟是有上限的。在正常情况下，整个直播中台接口的QPS峰值会在几万这个数量级。但是，我们也要考虑到直播过程中万一出现某些故障，可能会导致正在观看直播的几百万用户短时间内进行刷新操作。从历史数据看，这有可能使接口QPS峰值增长4-5倍。因此，直播中台在准备资源时，需要按正常峰值的10倍进行储备。

HA考虑

由于直播的时效性，显然不可能有充足的时间在直播过程中处理可能发生的故障。因此，多集群HA方案也是必不可少的。

简单来说，直播中台的架构可以分为QLB（接收外网流量）、nginx（处理路由和缓存）、tomcat（执行业务逻辑）、数据库和中间件四层。那么，非常容易想到的HA架构，如下图所示：

本着越简单越稳定的原则，我们可以对直播中台的HA架构进一步优化。对于一场直播节目来说，每个客户端需要从直播中台获取的数据可以分为两部分：所有人都一样的静态数据(比如节目ID、节目开始时间等)，每个人特有的动态数据。客户端只要能获取到静态数据，就可以保证节目能够开播。

所以，在备份集群上，我们做了nginx的缓存预推功能，通过脚本提前生成静态数据的缓存信息，预推到nginx服务器上。这样，即使tomcat或中间件出现大面积故障，甚至整个主集群都不可用了，只要nginx备集群还能工作，也能保证客户端的正常开播。这种情况下，流量都会导入到备集群，如下图所示：

降级方案

再考虑极端情况：如果直播中台的主备集群同时出现故障，能否给客户端提供最基本的观看直播节目的能力？

仔细梳理客户端的行为，如果只是为了播放视频内容本身，那么只要有节目ID就可以了。因此，客户端也配合进行了改造，初始的节目ID可以从资源位静态配置信息中获取。万一整个直播中台的接口都不可用了，那么客户端就以这个初始的节目ID进行播放，保证视频播放器本身是有内容可播的，但其他的节目介绍、互动功能等都不可用了。

资源文件下****载

假设一个资源文件的大小为1MB，10万用户同时进行下载的话，所需的带宽为1M*10万*8=800Gbps，这是一个在春晚直播过程中需要慎重考虑的带宽量级了。

首先想到的解决办法是提前下载。爱奇艺的月活用户在几亿的量级，期中只有千万量级的用户会观看央视春晚直播，因此，给所有用户预推直播资源文件，并不是一个最佳方案。

既然不能提前下载，那么能否延后下载，达到削峰填谷的效果？我们发现这是可行的。大部分情况下，用户进入直播间时不会立即用到资源文件，因此可以随机延后一段时间再下载。

直播播放服务：起播和清晰度切换

---

视听体验的提升：直播视频4K、1080P50的支持

为提升用户播放观感，TV端接入帧绮映画功能，除此之外还会分大小屏来对HDR_VIVID码流进行分端露出，这样能使在不同端露出最适合的码流，给用户最好的播放体验。

而针对体育内容而言，体育侧也支持了1080P60及其HDR码流的露出，这不光提升了视频播放的竞争力，也提升了观看体育直播的用户的播放体验。

如下图所示，分别是2024年春晚TV端支持帧绮映画以及体育支持1080P60帧的截图：

应急管理能力：直播码流管理平台

地域、运营商码流控制能力

为保障大型直播的顺利进行，降低CDN等平台的承载压力，直播码流管理平台提供了根据直播节目ID、城市(省份)、运营商等条件来控制码流露出的功能。

• 区域管理：在平台界面，配置上直播节目ID以及确定哪些区域露出哪些清晰度的码流来对不同区域的带宽进行降压处理。

• 黑白名单配置：该功能比上述的根据地域和运营商控制码流露出的功能更加灵活，可以根据请求端、请求来源、直播节目ID等条件来对码流设置白名单或黑名单，配置的极速发布也需要大概5分钟左右时间也会全国生效。

管理操作的便利性提升

直播码流管理中台作为直播播放配置中心，其存放多种配置数据，里面key很多都是由开发人员根据业务灰度或控制等需求添加并维护的，其值只有需求开发人员最为了解，有时需要两者配置控制，紧急情况运维时运维人员不知正确的配置，需要现场查代码确定，这极大的拉长运维时间，扩大线上问题的影响范围的可能性，为了解决该问题，直播码流管理平台提供了关键配置运维白屏化的工具，该工具把业务配置项变成运维人员可理解的配置，并可实现一键配置生效，前提是业务人员提前在白屏化页面对复杂业务配置项提前进行配置，确保配置的正确性。

• 比如《关于自动播放降级》的配置，在白屏化改造之后，如果线上出现问题，运维人员可以根据出问题的端等条件来从下拉框中选择相应的配值，点击保存，直接就可生效，降低运维人员因不熟悉业务导致问题扩大的可能性。

直播服务的可用性提升

统一各端对齐重试策略

• 背景：目前请求直播服务的主要端有爱奇艺自研播放器，各端系统播放器等。各端对直播服务在各种异常情况下的重试策略均不一致，主要有各端上开发同学控制维护，而重试策略对服务影响很大，一旦重试出现问题，服务端可能出现雪崩现象，直接导致服务不可用，为此我们经过讨论后定出以下目标。

• 目标：

• 优化客户端与服务器端重试策略，以应对各种异常情况下端上均能正常播放

• 统一重试策略：是否需要重试，如何重试，重试多少次等策略统一

如上图，在客户端请求完服务端后会出现3类错误，归类如下：

1. 连接/读取超时

2. 服务端返回httpcode >= 400的错误码

3. 服务端返回httpcode == 200码 + 业务错误码（如st-800，表示内部请求会员失败）

针对上面3类错误，我们分别定制了对应的重试策略，如下：

• 连接失败或读取超时后，端上需要使用fastdns及超级管道等途径进行重试；

• 如果httpcode 返回5xx时，端上则使用retry域名重试；

• 如果返回httpcode200+业务错误码，则端上需要使用直播服务返回的retry域名进行跨机房重试，而哪些错误码需要重试及重试多少次则由直播服务侧控制；

• 实施：

在制定完目标及方案后，我们就联手各端开发同学，测试同学，在项目同学的组织下集中评审，排期开发，组织测试验证及线上演练，最终在春晚之前各端开发完成并完成线上发版。

• 线上演练验证：

在上面各端各模块开发完后，为了验证此功能正常可用，我们又组织了各端测试同学进行线上演练。

• 验证case设计：

  由于涉及到的测试同学比较多（各端测试同学），加上上面3类错误重试逻辑让测试同学理解起来有一定的困难，因此经过讨论，把这些复杂的逻辑透明化，测试同学只用测试指定的几个视频是否可播及清晰度是否完整即可。而在这几个视频的背后，我们做了很多工作，如下：

• 首先测试同学播放视频A, 如果出现某个指定的错误码（线上环境不会出现），则说明端上正确连到了我们的验证环境（由于直播接口的重要性，为了避免用户通过配置host,改dns等方式劫持请求，端上做了很多校验，因此需要先确保端上测试验证时连接到了指定的直播服务环境）

• 区分正常请求和重试请求，只有正常请求才返回错误，通过重试域名的重试请求返回正常

• 为了确保测试同学在验证可播状态时数据是来自重试域名的，我们需要对重试域名的请求做一定的改造，如不返回1080p及以上码流，以便于区别线上正常请求。

• 由于这次的重试策略涉及多个场景，为了都能够得到验证，我们需要对每个场景定制出一个视频，即当测试同学在播放视频B时是为了验证httpcode5xx场景的重试策略；当测试同学在播放视频C时是为了验证httpcode200+业务800错误的场景重试策略

• 验证过程：

  顺利的话，只需各端测试同学验证一次，都符合预期，完美大吉。但现实往往到处都是坑，需要我们去趟平。直接说结论吧，此功能我们共协调验证了4次（天）才最终符合预期，其中第一第二次验证均发现某些端的实现有些问题，第三次是验证临时方案，第四次是长期方案都符合预期。期间发现存在问题的端，我们跟进催促解决上线，都耗费了很多的工作量，前后保守来说持续了1个月的时间。过程虽然艰辛，但最终的结果还是令人满意的，再次感谢各端开发测试同学及项目同学的大力支持。

直播线上全链路压测

因为直播节目一般都是在明确的某个时间点开始直播，所以大批量用户会在直播开始时的短时间内进入页面观看直播，这会导致直播服务接口的请求量会在瞬间急剧上涨，给服务端造成极大的压力。为了避免服务被压垮，我们联合测试、会员及其他全链路同学对线上服务多次高压极限压测，其中完成对3大机房各最大10w qps压测（包括付费和免费节目），并跟进解决了发现的matrix缺失、nginx运行时错误等问题。

直播线上攻防演练

为了验证直播服务的健壮性，我们对依赖的数据库中间件（CB）攻击（cb网络故障或节点异常都能进行降级）、外部依赖（直播后台接口、boss接口）故障（执行对应的降级策略）、机房灾备切流（运维工具可靠性）、突发流量攻击（限流熔断）等课题进行演练，最终整体结果符合预期。

 04

视频切片下载与播放

P2P下载数据

通过直播P2P分发系统下载切片数据，可以一定程度减轻春晚时的CDN带宽压力。我们将LCache部署在网络质量和稳定性较好的网络资源上，将Inside部署在性能较好的盒子设备上。

Lcache：从CDN拉取数据。

Inside：从CDN、Lcache拉取数据，也可以向其它Live-Inside请求数据。

Livenet：从CDN、Lcache、Inside获取数据，并提供给播放器。

春晚直播P2P分发方案的制定。为了保障不同运营商、各地域的用户都可以获得足够P2P资源，我们根据往年春晚时，以及跨年晚会时的各码率、地域、运营商的数据比值，作为参考依据来制定今年春晚直播P2P的分发方案。在选择分发的Inside设备时，优先选择性能较好的x86和arm64设备，实际上传比达到了4.6倍。

Livenet关闭m3u8依赖

Livenet请求m3u8小文件，对春晚超大规模的直播系统存在潜在大的风险，会导致CDN边缘节点可能抵挡不住春晚这个数量级小文件请求量。为此livenet紧急发布一个版本，可通过云配关闭对m3u8的依赖，由客户端自行推算切片名称来下载数据。上线后小文件的请求数据明显减少，缓解了小文件的回源压力。

预防错误数据扩散

校验机制：网络劫持会产生错误数据，而P2P系统则可能会放大劫持导致的错误数据造成的影响。我们通过完善的校验机制来保障错误数据不会在P2P系统中扩散。大致流程如下：每个切片文件都会生产一个对应的.pct文件。使用.pct文件里的crc信息来保证数据的完整性。而.pct文件的安全性，则是通过PublicKey来签名验证。PublicKey只有通过https请求获得。

故障演练**：**实时监控6-2-1（错误数据）的变化。一旦发现异常，则演练通过将Lcache、Inside全部下线来阻止错误数据在P2P系统中的扩散。

 05

总结

春晚直播涉及到的链路非常长，链路上的每一个环节都需要做好充足的准备，并充分考虑每个环节对整体链路的影响。2024春晚直播的准备过程中，我们总结的经验和所做的各种预防性工作，对于将来的春晚及其它高并发直播，都具有借鉴意义。同时，将来的每一场直播，都必定会有各自的特点，并出现新的挑战，需要我们继续打磨每一个环节，不断提升爱奇艺直播的稳定性保障能力。