字节跳动千万用户量级直播活动技术保障实践

罗永浩的带货首秀直播间观看人数达到千万级，LiveXLive 直播 48 小时不间断，字节跳动如何保证这些直播活动稳定无障碍？直播的全链路流程是什么样的？哪些指标能衡量直播服务的质量？如何满足千万级别用户对直播平台高并发的挑战？

本文整理自字节跳动火山引擎高级开发工程师徐永康在 InfoQ 技术公开课的分享。本次分享主要围绕事件直播全链路窥探、字节跳动直播重保实践、如何一天内让清北网校拥有稳定直播能力等几个部分进行展开。

以下为分享内容：

今天给大家带来的分享是字节跳动千万用户量级直播活动技术保障实践。

我们先来看一下直播的全链路是什么样子的。

直播全链路

一般来说，直播都是从音视频的采集开始的，有屏幕采集、摄像头采集，还有声音的麦克风采集。视频是 YUV/RGB 的格式，音频采集后是 PCM 格式。然后，我们会对采集过来原始信号进行音视频的处理，比如进行美颜、加水印、加滤镜等工作。

音视频处理之后，需要对一些 YUV、PCM 格式的裸数据进行压缩处理。因为这些数据量级非常大，每秒钟传输需要几百兆的带宽，我们现在的网络带宽环境是承受不住的，所以要对音视频进行压缩处理。目前业界主流的视频压缩算法是 H264，大家也都在往 H265、VP9 方向发展。经过音视频的压缩之后，视频信号就变成了 H264 信号，音频就变成了 AAC 信号，也叫 ACC。然后，我们把经过编码器压缩之后的数据，放入推流设备中。推流设备会进行 FLV 的打包，变成 FLV 的封装格式，用 RTMP 的协议进行推流。

推流一般就是用 CDN 来进行加速和分发。用户的播放就是一个推流的逆向过程，先接到压缩后的数据进行解压缩，解压缩之后拿到 YUV 和 PCM 数据放入播放器，再进行画面的渲染、音频的输出。

大家可以看到整个音视频的处理过程，链路是非常长的，在实际直播过程中，我们也会遇到一些问题。

比如音频的音画不同步问题，可能是用户看到主播张嘴说话了，但是没有声音，声音延迟了。这些对于用户的感官来说都是非常不舒服的。我们的经验是，延迟如果超过 200 毫秒，用户就会有非常明显的感知。

还有音频反向，这个在实际直播中确实遇到过。在早先一次直播中就出现过音频反向的问题，当时一位歌手在唱歌，但中间有一段，唱歌的声音听不到，只听到一些伴奏，其实是在扬声器合成的时候，部分音频相互抵消了。

除此之外，也还会遇到一些音频方面的爆音、静音等问题。

对于视频的话，会有一些比如摩尔条纹的问题、清晰度低的问题。清晰度低的原因可能比较多，比如摄像头采集过来的分辨率本来就不高；或设置的编码器参数不太合理，或者推流设备参数设置不合理。类似码率、分辨率设置的比较低，就会让用户感觉清晰度低，甚至会出现马赛克。还有就是有边缘锯齿现象，比如我们采集的时候是隔行的，推流的时候是逐行的，在没有做交织的情况下，就会有边缘锯齿。

链路中还有流分发过程，流分发是借助了 CDN 的加速。

简单说一下这个环节。首先我们通过推流设备进行推流，会把它通过 DNS 解析到 CDN 边缘节点，也就是离用户最近的一些节点。边缘节点会把音视频数据推到上层节点，再推到原站。当用户拉流的时候会从解析到的边缘节点去拉流，边缘节点有流的话，就会直接传给用户了。特别情况下，当用户第一次进入的时候，边缘节点没有流，它就会回源到上层去拉流，如果上层没有流，还会回源到源站。

整个 CDN 加速的过程，其实也是比较复杂的。这么长的一个链路，也会出现一些问题，比如边缘节点故障、上层节点故障、源站故障，这些都会对用户造成或多或少的影响。边缘节点故障如果出现在上行链路上，那就可能对所有用户都造成影响，如果出现在下行链路，那可能只是影响部分的用户。

还有转码故障。转码故障可能导致用户看不了转码流，只能观看源流。这种情况下，一般码率比较高，用户会感到明显的卡顿。

除了这些节点故障，还有跨网传输。刚才讲到边缘节点一般是离用户最近的，同网、同运营商、同区域内。但是如果 DNS 解析不正常，出现了跨网传输，就会极大影响体验。比如北京联通的用户，从北京移动去拉流，这样的网间传输就会带来非常大的质量问题，可能会拉不到流，或者是直播画面变得非常的卡顿。

还有一种情况是带宽不足。我们一些大型的直播，它的人数是非常多的，可能是上千万人，这样的话，是任何一家 CDN 都扛不住的。然后还会有些区域覆盖，特别是有些区域的 CDN 节点比较少，这样就会有一些跨网的覆盖，或者是跨运营商的覆盖，用户量也是会感到有明显的质量的变差。

那我们如何去评价直播的质量？一个就是 QoS 指标，QoS 就是服务质量，目前有五个指标：拉流成功率，百秒卡顿时长，百秒卡顿次数，端到端延迟，首帧时长。

拉流成功率表示用户能够成功拉到流的比例是多少，拉流成功率低，说明这个流几乎是不可用的。百秒卡顿时长和百秒卡顿次数直观的描述了用户观看的过程是否流畅。端到端延迟，也叫挥手延迟，就是说主播在这端挥挥手，到用户能够看到这个挥手的动作，中间所持续的时间是多长，主要需要降低端到端延迟。首帧时长是从点开直播，到看到了第一帧画面中间所持续的时间。

这些 QoS 指标，我们会更细化到一些维度上面去，比如就是直播流、清晰度、主备线路、CDN、应用、省份、运营商、操作系统、版本号等等。我们通过这些维度能够很快的归因出，目前影响直播质量的到底是哪一个环节。

还有 QoE 指标，就是体验质量。QoE 指标有次均观看时长，同时在线人数，还有万条评论报卡率。特别是次均观看时长和同时在线人数这两个是比较相近的，如果它出现较大的变化的时候，比如用户突然之间走了并不一定是服务出现问题，它也可能是直播内容不够精彩，这时候次均人员观看时长、同时在线人数就会有一个明显的下降。

但是反过来，如果要是 QoS 指标出现问题，那么它一定会影响到 QoE 指标。比如说拉流成功率突然降低了，CDN 的结点出现故障了，这时候很多用户是被强迫卡出去的，并不是我们的内容不精彩，在同样内容情况下，是用户看不到流了进不来了。这时候我们的次均观看时长会降低，同时在线人数也会降低。这两者有相互借鉴的一个作用，应该两个结合起来去看问题，

然后万条评论报卡率就是我们发评论的时候，主播可能是看不到的。比如主播是在全屏分享 PPT，但是大家可能会在评论区发一些关于直播内容的消息，比如他们会说“好卡，已经卡了”。这些其实是非常重要的一些信息，我们可以把这个评论的内容收集过来，作为一个 QoE 指标，将这些报卡的用户比例与百秒卡顿时长、百秒卡顿次数这些 Qos 指标相互借鉴，我们会发现，报卡率也是一个非常正向的，非常有借鉴意义的一个 QoE 指标。

还有清晰度的问题，比如说画面质量模糊，有马赛克，看不清，这些也是一些 QoE 指标。我们目前也在梳理这些，我们也想把它作为一个评论画面质量相关的一个 QoE 指标。这个 QE 指标我们也把它细分到好多个维度：直播流，清晰度，主备线路，CDN 度，应用。

事件直播

刚才给大家简单介绍了直播的全链路是什么样子，也列出了各个环节可能造成的质量相关的问题的风险点，以及如何用 QoS 和 QoE 指标去评价直播的质量，对直播的质量进行量化，如何去优化这些直播的质量，现在我们就来看一下字节跳动在事件直播的过程中一些重保实践。

首先说一下什么是事件直播。简单举几个例子，比如抖音盛典，西瓜 Play，头号英雄，头条盛典，跨年直播，火山盛典，LiveXlive48 小时不间断直播，罗永浩的首秀，当然还有一些明星的直播，比如汪峰、王祖蓝、陈赫、AngelaBaby、张庭，他们都进行过直播带货。除此之外，还有草莓音乐节，SpaceX 发射，清北网校在线课堂等等，这些都是属于事件直播。

通过这些关键词，我们可以简单的概括事件直播是由组织发起的、非日常的开播，不是一个人对着手机或者是游戏的开播。它的目的性比较强、主题比较明确，比如明星直播带货，它的目的就是直播带货；头条盛典，火山盛典，抖音盛典，它们都是一场晚会。还有一个特点是影响力比较大，受众广泛。每一场事件直播都有很大的目标群体，动辄就是几十万，上百万，甚至近千万的用户观看。

对我们而言，事件直播是值得花大力气去保证的直播。这么多的直播类型，形式都非常的不一样，有的是一个机位，有的是多个机位，很难面面俱到的去覆盖每一场场景，很难有一个统一的重保规范去覆盖这些场景。重保需要 case by case 的去分析，梳理过程中可能存在的风险点，然后制订一些重保方案。

通过这些的重保活动，我还是梳理出了一个比较通用的直播重保架构。

大家可以看一下上面这个图，首先信号采集部分，可能会有多个机位，多个信号源。信号源把信号传输到导播台，导播台进行信号切分，最终会把信号传到延迟器。延迟器把信号传到推流器，推流器进行音视频的编码，压缩，然后把它推到 CDN 网络上去。上行是一个 CDN，下行可能会挂在多个 CDN 去分发，就是多条线路，然后用户从这些线路里面去选择其中的一个去进行观看，这是主要的流程。

通过上图，大家可以看到，其中比较明显的是从导播台出来的信号是完全翻成了左右两部分，就是主、备线路。左边是个主线路，右边是个备线路，主备是完全正交的。左侧任何一个节点出现问题，都可以让用户去用备线路去拉流，这个也是自动实现的。

那么导播台这个地方为什么没有去用主备导播台呢？主要是因为导播台是有旁通的功能，它都是一些硬件设备的，至少目前是没有出现过故障的，还有就是如果即使换成主备导播台，就要求主备导播台出的信号完全一致，但这个不是能够轻易现实的。

然后延迟器，上图虚线部分，意思是说延迟器我们是可以选择的。延迟器的作用，主要是对内容进行容灾。比如有些舞台事故不希望让用户看到，就会在延迟器里把事故的片段切掉，这样用户看到的是一段跳过去的内容。还有就是垫片，我们把它同时放到了导播台、推流器、上行 CDN。有些不同的容灾的级别，比如传入的信号出现了问题，这时候用导播台去推垫片，然后把垫片放到推流器，我们容的是导播台、延迟器这一层面的故障。也就是说进推流器的音视频信号出现问题，我们就用推流器去推这个垫片，让用户看到的主备还是一样的。不至于看到一个空白的黑屏，或者是说是一直在那里转圈圈。

还有大家可以看到导播台出来了一个旁路信号，就是进了监视器，这个监视器代表着从导播台出来的信号是被用户可以看到的内容。

我们这里能够完整呈现包括导播台输出的音视频的信号，一个是有个画面显示，另一个是有一个录制功能，能够在这里把信号录下来。前面提到的一个活动上出现的音频反向，就是通过这个监视器录制的信号，让导播团队知道是他们导出来的信号有问题。且不是在延迟器，或者是推流器，或者是 CDN 这一层面出现的反向问题。还有主备 CDN 下面会挂载多个线路，是为了容灾，每个线路都是一个 CDN 进行分发，其中线路一出现了问题，我还可以让用户切换到线路二和线路三去。

另外一些大型直播的用户量级非常大，一条 CDN 线路是没法承载这么多用户的。所以也得需要多个线路、多个 CDN 去共同承担用户的直播分发。我们有专门的人员划分去进行不同的重保。人员划分主要分为上行容灾、下行容灾，还有体验容灾。对直播上行来说，主要是容的网和电。我们会在现场备一个 UPS，就是不间断电源。即使市电断了，我们也可以再用 UPS 撑很长一段时间。网络一般看活动的重要程度，有可能会拉专线，也有可能是用 4G 和 Wi-Fi 互备。当然也有可能是用聚合路由把信号聚合起来。

除了网和电的容灾，还有是对内容的容灾。比如推垫片，还有延时器的裁剪，这些是上行的一些容灾措施。

下行的保障，主要是通过链路层面的保障能正常推到 CDN 上去。但是用户观看可能是受影响的，这时候我们可能会有一些主备切换。

另外还有清晰度的降级，主要转码流故障，或线路的调整，或 CDN 线路出现问题，我们会切换到另一个 CDN 线路上去。

还有一部分是负责体验容灾的，就是体验保障。当用户反馈卡顿，或者是不清晰，这时候会设置播放器的缓存，通过增加缓存来减少用户的卡顿。还有区域运营商线路调整，当用户在某一个区域运营商的时候比较卡顿，比较有集中性，那我们就会把这一个区域运营商的用户换 CDN 去覆盖。节点的调整，是某一个节点下的用户出现问题，就让用户去用别的节点去覆盖，从别的节点去拉流。降级的操作主要有音视频信号的同步处理，音频单声道拷贝，主备切换，拉流转推，设置房间默认清晰度，降低转码码率，摘除转码，调整 CDN 权重。设置播放缓存，区域运营商切换 CDN，节点优选，下掉 CDN 节点等等。

直播质量优化

直播质量的优化，首先是对普通用户的优化，就是转码档位设置。提升清晰度，一般情况下是提升码率或者分辨率。但是什么样的码率配置什么样的分辨率是需要去做尝试的。首先我们得有一个平台把不同编码的左右两个图片参数编出来，然后进行对比打分，同样的码率下是 480P 还是 540P 更加好一些。

除了主观打分，还有一些客观的质量评判标准来进行评判。我们可以看到，并不是随着码率升高，清晰度是一直往上增加的，达到了一定的程度后，其实会趋于平缓，这时人们就感受不到码率变高带来的清晰度的改善。然后我们的经验是说在 1M 以下，会分发 480 P。在 1-2M 之间，可能会分发 540 P。在 2M 以上，可能就会分发 720 P。

还有针对一些弱网的用户，是网络不太好的用户，比如 4G 用户到了月底限流了，只能用几百 K 的速度带宽去观看直播，这种情况我们其实也有一些优化，通过传输协议和丢帧策略优化。

现在国内主要就是 FLV，然后还有 HLS，RTMP，但是所有底层的传输协议还是用的 TCP。TCP 的超时重传、拥塞控制都不是那么好改变。除了 TCP 还有 UDP。UDP 没有三次握手，包头会比较小一点，这样传输会更快一些。比如 KCP， QUIC，是基于 UDP 实现的可靠传输。

丢帧策略有优雅丢帧、传输层丢帧、音视频分离。音视频分离其实是一种更极端的丢帧方式。在非常卡的情况下，我们可能只播放音频，不播放视频，这样的话相当于把视频全丢掉。

具体怎么样选择协议和策略，我们可以通过上图来看。首先我们对用户的播放器日志进行收集和数据分析。通过时段、设备类型、国家城市、运营商、观看时长这些，最终去进行识别分类出一些指标，比如 RTT、丢包率、带宽、活动周期、码率、观看时长、卡顿数据、清晰度。然后把这些指标应用于模型训练。通过模型我们进行策略的匹配与下发。决策出当前用户在当前的网络下，用 TCP 还是用基于 UDP 的 KCP 、QUIC，以及初始参数、拥塞策略、丢包策略。同时根据最终用户的观看效果，QoS 指标和 QoE 指标效果反馈到网络模型上去进行进一步的优化。

除此之外我们还有对一些特征的私有化部署。之前我们有一场发布会活动，我们没有想到用户会有那么多，当时几乎是所有的同事在办公环境下一起观看直播，分配下来每一个人几兆带宽。因为都是从公司的入口网关处拉流进来，这样最先崩溃的是我们公司的网络入口。这种情况下，我们就需要通过私有化部署来解决这个问题。现在我们内网的一些分享之类的全都通过私有化部署来解决了。

私有化部署是把 CDN 的边缘节点部署到人员比较密集的地方去，比如每个办公区部署一个节点。比如图中紫色的部分，就是边缘节点，绿色的就是一个办公区。所有办公区的用户，我们通过 DNS 劫持，把他们通过同一个播放地址去拉流。私有化部署带来的好处一个是信息安全，防止泄露，有一些活动分享其实是有保密性的，不希望能够被外界感知到，所以私有化部署就很好地解决这个问题，并能解决入口带宽的瓶颈。

直播赋能

赋能的一个比较典型的例子，就是在疫情期间，一天时间我们让清北网校拥有了空中课堂的直播能力，并且保证了直播的稳定和质量。上图是清北网校的网站，首先给直播开辟了一个单独的入口，为全国中小学生免费提供直播系统。快速搭建清北网校主要得益于下面 5 点：

• 一个是快速搭建页面的能力，就是所见即所得。

• 页面组件化，一行代码能够迁入。

• 完善的直播保障和容灾体制机制。

• 支持推拉入等多种开播方式。

• 支持字节旗下的多平台互通分发。

我们会用一个平台重保管理，有一些操作都能够自动进行，比如可以通过指示灯表述直播状态。我们还可以进行自动巡检，判断是否可以自动做一些降级操作。我们还可以记录历史的报警信息等等。同时我们也提供了这个直播伴侣，客户端，用直播伴侣客户端可以直接进行开播操作。