发布会直播技术及业务实践
时间：2021-08-19 16:29:55
手机看文章
扫描二维码
随时随地手机看文章
[导读]一、背景随着直播行业的近年来的发展，直播技术现已日趋成熟。本文主要介绍目前主流的直播技术原理，以及在直播在发布会场景下的应用以及过程中遇到的问题及解决方案。二、直播原理2.1流媒体技术2.1.1流媒体简介目前在网络中传输音视频的多媒体信息主要有两种方式——下载方式和流式传输。下载...
一、背景
随着直播行业的近年来的发展，直播技术现已日趋成熟。本文主要介绍目前主流的直播技术原理，以及在直播在发布会场景下的应用以及过程中遇到的问题及解决方案。
二、直播原理
2.1 流媒体技术
2.1.1 流媒体简介
目前在网络中传输音视频的多媒体信息主要有两种方式——下载方式和流式传输。下载方式很好理解，用户需要将一个音视频完全下载后才可以进行播放；流式传输指将音视频通过服务器向客户端进行连续的实时传输。基于流式传输的特点，就不难理解流媒体的定义——流媒体（streaming media）是在由提供商提供的同时能够不断的被终端用户接收，并呈现给终端用户的多媒体。动词“流”（streaming）很好的描述了这种媒体的传递和获取的过程。
好比一个完整的word文档，我需要全部下载才可以打开，甚至下载完给我来一个损坏提示，相比这时候心情一定十分恼火，但如果一页一页进行下载，像小人书一样呢？
图1：word示意图
图2：小人书示意
2.1.2 流式传输概述
所谓流式传输是指将整个A/V等多媒体文件经过特殊的压缩方式分成一个一个的压缩包，通过服务器将这一个个的压缩包向终端用户连续、实时发送，用户还没有接收到完整的多媒体信息前就能处理已接收的部分信息，并对该部分音视频进行播放，剩余部分继续在服务器后台下载。（类比计算机处理问文件的方式）。
流媒体传输主要分为以下两种方式：
2.1.3 流媒体技术与直播
由于流媒体技术的快速发展在一定程度上突破了网络带宽对多媒体信息的限制，将过去的传统媒体的“推”式传播转变为用户可选择的“拉”式传播，用户可根据自己的喜好选择性的接收自己需要的媒体信息。正是这种技术和时代的进步使得如今直播平台快速发展，丰富的业务也能扎根直播完成其使命。
2.2 直播流程
了解直播所需的基本概念后，咱们再一步步走进直播的原理。
首先在聊直播的时候，我们需要了解直播涉及到的三大角色——主播、流媒体服务器和观看用户。顾名思义，主播就是视频的发起者，我们称为视频录制端或视频推流端；观看用户就是收看直播节目的受众，我们称为视频播放端（拉流端）；而流媒体服务器是两端的桥梁，承担着处理流媒体及分发的任务。这三者构成了直播的整体流程。
图3：直播流程
2.2.1 视频推流端
视频推流端工作流程主要分为四步：
2.2.2 流媒体服务器
流媒体服务器是流媒体应用中的核心系统，是运营商向用户提供流媒体服务的关键平台。当主播使用推流软件将流媒体推送至各种流媒体服务器之后，流媒体服务器可以将获取到的媒体内容进行加强、转码等各式各样的操作，同时服务器可根据解析出来的媒体内容进行额外的业务拓展如安全审核等，最终服务器会将处理好的媒体内容以合适的流媒体协议将流媒体内容传输至CDN，观看用户端便可以随时拉取媒体内容进行播放。
2.2.3 播放端
也称拉流端，用户可使用各种流媒体播放app拉取想要获取的信息。
播放端的步骤如下：
通过以上几个步骤，用户端就能够顺利的开始播放直播啦。
2.2.4 直播架构
为完成2.2所述直播流程，一般直播架构如下：
图4：简单直播架构示意
2.3 直播协议
光有思路了还不够，数据传输需要一定的规范，否则各家按各家行事到时候都只能在自己的框架里才能玩得转，不符合互联网共享精神，这时候就需要有一套规范的协议来约束数据的传输。
常见的直播协议有RTMP、HTTP-FLV、HLS 等，下面我们来简单介绍一下这三种协议。
2.3.1 RTMP
RTMP协议是Real Time Message Protocol(实时信息传输协议)的缩写，最初是Macromedia（现归Adobe所有）开发的专有协议，用来解决多媒体数据传输流的多路复用（Multiplexing）和分包（packetizing）的问题，可在Flash播放器和服务器之间通过Internet流式传输音频，视频和数据。是一种应用层协议，同时支持推流和拉流。
RTMP传输时，会对数据内容进行格式化，这种消息格式被成为RTMP Message，该消息的构成如下：
图5：RTMP 消息构成
可以看到根据Message的TypeId可以划分为7种信息，这7种信息包含了对端连接、数据信息及控制信息等，用以完成流媒体的播放及操纵。
根据视频数据“压缩分段”的思想，RTMP在实际传输过程中会将Message划分为一个个带ID小块，称为Chunk，每一个Chunk可能是一个单独的Message，也可能是一个Message的部分。每一个Message都有一个唯一的标识——Message Stream ID，在还原Message时，每一个Chunk就通过这个标识来辨别是否为同一个Message，最终在收到Chunk后进行组装。
RTMP的推拉流流程如下：
图6：RTMP 推拉流过程
感兴趣的小伙伴可以参考Adobe官网发布的 RTMP specification v1.0对RTMP进行更深入的了解，本文不再赘述。
2.3.2 HLS
不管是RTMP还是HTTP-FLV，都逃不过一点——Flash。在12年Adobe发布RTMP specification v1.0时，本以为拿到流媒体金钥匙的Adobe未曾想未来是个HTML5的世界，一个不需要Flash的世界。
在09年三月iphone 3.0发布会上，苹果在新的操作系统宣传中添加了关于流媒体功能的微妙暗示。同年五月HLS协议正式发布。HLS协议的出现最初是为了解决苹果原生环境中的流媒体播放问题，这个协议可以方便的让Mac和iphone播放视频流而不依赖Adobe。依赖自己往往是最大的力量保障。
HLS全称HTTP Live Streaming，是一个由 Apple 公司实现的基于 HTTP 的媒体流传输协议。工作原理是通过将整条流切割成一个小的可以通过 HTTP 下载的媒体文件, 然后提供一个配套的媒体列表文件, 提供给客户端, 让客户端顺序地拉取这些媒体文件播放。
HLS协议包含三个部分：Server、Distribution 和 Client.
图7：HLS 处理流程
通过上述流程，用户拿到索引文件就相当于拿到了流媒体的钥匙，那么HLS生成的索引文件又是啥呢？让我们来解开他的神秘面纱——m3u8文件。
m3u8文件实际实质上是一个播放列表（playlist），其主要的两种形式为主播放列表（Master Playlist）和流媒体播放表（Media Playlist），也称一级索引和二级索引。
图8：m3u8文件内容
可以看到主播放列表（一级索引）主要标识有带宽（BANDWIDTH）、视频分辨率（RESOLUTION）、音频编码格式（CODECS）以及二级索引路径；流媒体播放列表（二级索引）关键属性为切片持续时间（EXTINF）以及视频切片路径（按上图实例，该切片至少有9.009 9.009 3.003秒左右的延迟）；浏览器通过不断访问最新m3u8文件即可获得每个切片的地址并通过浏览器进行播放。
图9：直播 m3u8请求
2.3.3 HTTP-FLV
HTTP-FLV本质上是RTMP在HTTP协议上的封装，同样都是传输的flv格式的数据，由于通过80端口通信，相比RTMP其穿透性更强。HTTP-FLV在本文中不再过多阐述。
2.3.4 三种直播协议对比及选型
三种直播协议的对比如下：
图10：三种协议对比
根据三种常用的协议对比，在直播协议的选择上面可根据各自的特点进行选择——实时性要求（互动直播等）：RTMP/HTTP-FLV 稳定性要求（发布会等）：HLS
2.4 小结
本章对直播原理及常用的三种协议进行分析，供读者了解直播技术中涉及的基本概念。可能有些读者对枯燥的技术知识表示“抗议”，在此以物流系统对直播系统进行类比以供大家轻松愉快地理解：
相信大家平时都有网上购物习惯，举个例子：小明要在网上给女朋友买一个加热出现照片的定制杯子，他会经历网上下单，物流运输、驿站存取等步骤，而商家担任产品的制作需要经历杯子加工、打包、发货等步骤；
在这里商家就是主播，杯子就是原始视频，加上小明女朋友照片的杯子就是经过了处理工序，而打包就是编码封装按一定的规格给快递公司才给正常发货嘛，而发货就是相当于推流，此时物流公司就担任流分发的重任，将快递分发到各个驿站（CDN），而小明的快递便传递到了最近的驿站；
小明想起来要去拿快递了，于是凭借着取货码（拉流协议），去拿到这个杯子，这个提货的过程就相当于拉流，整个过程如下图所示：
图11：物流系统类比图
相信通过这个形象的例子，大家一定对直播架构有了基本概念。
三、vivo官网发布会直播技术保障
3.1 发布会直播面临的挑战
本章主要介绍在vivo官网发布会直播过程中所遇到的问题，以及其一般性解决思路。新品发布会的影响力可想而知，特别是在发布会push发放节点以及发布会开始节点，会有大量的观众进入到官网直播间，此时的瞬时压力成为面临的第一道挑战，而随着发布会的进行，持续大流量也成为系统的隐患之一；当然由于发布会的特殊属性，一切都建立在不容出错的基础之上，保证发布会无异常发生。
可以看出发布会直播面临的问题实际上就是一个典型的高并发系统所面临的问题。而保护高并发系统的三大利器——缓存、降级、限流，便是发布会技术保障其中的一部分。
3.2技术保障
3.2.1 发布会缓存方案
正所谓网站性能优化第一定律就是考虑使用缓存针对发布会我们做了许多缓存优化方案。
细心的小伙伴会发现官网直播涉及到内容轮询获取，如直播人数、直播评论、点赞数等，而优化的第一步是调整轮询的时间间距，减小峰值QPS；而降低QPS后仍然会有大量请求过来，这时候作场景考虑，部分配置信息以及围观人数、点赞等对发布会主流程无决定性影响且实时性要求并不高，而采用单纯的redis集群会使得集群压力剧增，最初直接集群访问的模式已不再适应业务的发展，此时在技术层面考虑了这部分数据采用本地缓存进行存储。虽然会造成短暂的数据不一致的“损失”，但在对业务没有实质性影响的情况下，极大的提升了直播业务的稳定性。
图12：多级缓存演变示意图
3.2.2 发布会降级方案
发布会场景的核心是保证直播音视频的正常播放，给用户了解咱们最新的产品。由于实际业务的需要与拓展，在发布会场景涉及到许多感知与互动元素，而如果因为这些业务功能导致发布会核心被拖垮显然得不偿失。所以在设计之初对这些业务设置了一些降级策略以防止这种情况的发生。在此举一种典型的场景以供大家理解进入直播页的第一道“工序”就是去查询直播的基础配置，而当访问量到一定程度通过观察日志发现部分请求超时甚至异常时，咱们就会开启强制熔断，后续查询就会走到fallback方法指向查询本地缓存中的内容，降低服务压力的同时也不会对用户的观看体验造成很大影响。
图13：熔断示意图
虽然上述方案在实际发布会过程中均未触发，但未雨绸缪有备无患总是比出现问题再解决问题来的更加从容自然。
3.2.3 发布会限流方案
发布会直播评论抽奖作为典型流量场景，使用限流手段让部分抽奖评论排队等待，后续等处理完毕后再告知用户中奖信息。常见的限流算法有漏桶算法和令牌桶算法，而评论抽奖的特性是到时间段的瞬间有大量评论进入抽奖逻辑，限流既要考虑流量整形，又要考虑突发请求，令牌桶算法再适合不过。
图14：令牌桶算法示意图
3.3 内容安全保障
由于面向公众，同时存在互动类玩法，内容安全性在发布会直播中也尤为重要，而在直播内容安全（即视频无敏感内容）的前提下，与用户侧相关的文字内容安全（涉黄、涉政、暴恐、违禁内容等）处理成为需要解决的一大问题。当然在内部谛听团队的支持下这一问题也迎刃而解，避免重复造轮子。
3.4 小结
通过本章作者希望大家理解直播的核心是给大家看视频听声音的，为了保证这一需求不出错的同时在上面进行一些拓展性的业务提升用户互动性需要面临诸多挑战，作为开发者需要意识到这些挑战并做好接受挑战的准备，为业务的提升打好基石。
四、写在最后
如今直播的业务存在形式多种多样，如发布会、游戏直播、教育直播、直播带货等，作者希望通过本文的介绍相信大家或多或少对直播技术有了一定的认知，直播涉及到的各个细节都有一个庞大的知识体系支撑，由于篇幅及个人知识经验有限，无法为大家呈现更多细节，有兴趣的读者可以以本文为参考对直播进行深入的了解。
随着直播行业的近年来的发展，直播技术现已日趋成熟。本文主要介绍目前主流的直播技术原理，以及在直播在发布会场景下的应用以及过程中遇到的问题及解决方案。
二、直播原理
2.1 流媒体技术
2.1.1 流媒体简介
目前在网络中传输音视频的多媒体信息主要有两种方式——下载方式和流式传输。下载方式很好理解，用户需要将一个音视频完全下载后才可以进行播放；流式传输指将音视频通过服务器向客户端进行连续的实时传输。基于流式传输的特点，就不难理解流媒体的定义——流媒体（streaming media）是在由提供商提供的同时能够不断的被终端用户接收，并呈现给终端用户的多媒体。动词“流”（streaming）很好的描述了这种媒体的传递和获取的过程。
好比一个完整的word文档，我需要全部下载才可以打开，甚至下载完给我来一个损坏提示，相比这时候心情一定十分恼火，但如果一页一页进行下载，像小人书一样呢？
图1：word示意图图2：小人书示意2.1.2 流式传输概述
所谓流式传输是指将整个A/V等多媒体文件经过特殊的压缩方式分成一个一个的压缩包，通过服务器将这一个个的压缩包向终端用户连续、实时发送，用户还没有接收到完整的多媒体信息前就能处理已接收的部分信息，并对该部分音视频进行播放，剩余部分继续在服务器后台下载。（类比计算机处理问文件的方式）。
流媒体传输主要分为以下两种方式：
- 顺序流式传输（Progressive Streaming）即用户在观看在线媒体的同时下载文件，在某一时刻用户只能观看已下载的部分而不能跳转到未下载的部分进行观看。顺序流式传输能够很好的保证节目播放质量，比较适合在网站上发布的、可供用户点播的、高质量的视频。典型例子——电视节目。
- 实时流式传输（Real-Time Streaming）这种传输方式需要保证媒体信号带宽与网络连接匹配，使得音视频可以被实时的观看，一般需要专门的流媒体服务器与传输协议。这种方式允许用户通过服务器对媒体发送更多级别的控制如快进、快退等，同时在传输过程中音视频质量能够根据用户的网络带宽进行调整。
2.1.3 流媒体技术与直播
由于流媒体技术的快速发展在一定程度上突破了网络带宽对多媒体信息的限制，将过去的传统媒体的“推”式传播转变为用户可选择的“拉”式传播，用户可根据自己的喜好选择性的接收自己需要的媒体信息。正是这种技术和时代的进步使得如今直播平台快速发展，丰富的业务也能扎根直播完成其使命。
2.2 直播流程
了解直播所需的基本概念后，咱们再一步步走进直播的原理。
首先在聊直播的时候，我们需要了解直播涉及到的三大角色——主播、流媒体服务器和观看用户。顾名思义，主播就是视频的发起者，我们称为视频录制端或视频推流端；观看用户就是收看直播节目的受众，我们称为视频播放端（拉流端）；而流媒体服务器是两端的桥梁，承担着处理流媒体及分发的任务。这三者构成了直播的整体流程。
图3：直播流程2.2.1 视频推流端
视频推流端工作流程主要分为四步：
- 采集：主播/导播通过摄像机、手机等录制设备进行音画采集；
- 处理：在导播台将原始音画进行一定的处理如美颜、加水印、滤镜等；
- 编码和封装：当原始视频被处理完毕后通过编码器如H.264、H.265等进行编码，将庞大的音视频源文件压缩，并通过封装将编码好的媒体内容封装为规范的媒体文件格式如AVI、MOV、MPEG格等；编码的核心思想是去除媒体信息中的冗余，包括：空间、时间、编码、视觉等；而封装的意义就好比用何种货车去运输货物（媒体内容），让播放变得简单。此步骤对流媒体传输有着至关重要的作用，涉及规范和知识也十分丰富，有兴趣的同学可以寻找相关文章进行了解，在此不进行详细说明。
- 推流：最终通过推流工具将该流媒体向服务器推送，“推”一动词形象地描述了主播主动将流推送至服务器的过程。到此步被成为直播的第一里程碑。
2.2.2 流媒体服务器
流媒体服务器是流媒体应用中的核心系统，是运营商向用户提供流媒体服务的关键平台。当主播使用推流软件将流媒体推送至各种流媒体服务器之后，流媒体服务器可以将获取到的媒体内容进行加强、转码等各式各样的操作，同时服务器可根据解析出来的媒体内容进行额外的业务拓展如安全审核等，最终服务器会将处理好的媒体内容以合适的流媒体协议将流媒体内容传输至CDN，观看用户端便可以随时拉取媒体内容进行播放。
2.2.3 播放端
也称拉流端，用户可使用各种流媒体播放app拉取想要获取的信息。
播放端的步骤如下：
- 拉流：通过播放app并选取合适的拉流协议进行拉取媒体内容；
- 解复用：将处于“多媒体文件格式”的流解复用，成为“视频编码格式”和“音频编码格式”，通俗点说就是把“音视频信号源”分流出单独的“视频数据”和“音频数据”。（如.FLV解复用后得到H.264视频数据和AAC音频数据）。
- 解码：硬解码（GPU解码 CPU辅助）或软解码（CPU解码）将解复用得到的音视频数据进行解码，解码后得到YUV或RGB格式的视频以及PCM格式的音频。
- 音画同步并输出播放：解码后终端会执行音画同步的操作，并将同步后的音频输送至音频设备进行播放，视频通过输送至视频输出设备进行播放。
通过以上几个步骤，用户端就能够顺利的开始播放直播啦。
2.2.4 直播架构
为完成2.2所述直播流程，一般直播架构如下：
图4：简单直播架构示意2.3 直播协议
光有思路了还不够，数据传输需要一定的规范，否则各家按各家行事到时候都只能在自己的框架里才能玩得转，不符合互联网共享精神，这时候就需要有一套规范的协议来约束数据的传输。
常见的直播协议有RTMP、HTTP-FLV、HLS 等，下面我们来简单介绍一下这三种协议。
2.3.1 RTMP
RTMP协议是Real Time Message Protocol(实时信息传输协议)的缩写，最初是Macromedia（现归Adobe所有）开发的专有协议，用来解决多媒体数据传输流的多路复用（Multiplexing）和分包（packetizing）的问题，可在Flash播放器和服务器之间通过Internet流式传输音频，视频和数据。是一种应用层协议，同时支持推流和拉流。
RTMP传输时，会对数据内容进行格式化，这种消息格式被成为RTMP Message，该消息的构成如下：
图5：RTMP 消息构成可以看到根据Message的TypeId可以划分为7种信息，这7种信息包含了对端连接、数据信息及控制信息等，用以完成流媒体的播放及操纵。
根据视频数据“压缩分段”的思想，RTMP在实际传输过程中会将Message划分为一个个带ID小块，称为Chunk，每一个Chunk可能是一个单独的Message，也可能是一个Message的部分。每一个Message都有一个唯一的标识——Message Stream ID，在还原Message时，每一个Chunk就通过这个标识来辨别是否为同一个Message，最终在收到Chunk后进行组装。
RTMP的推拉流流程如下：
图6：RTMP 推拉流过程感兴趣的小伙伴可以参考Adobe官网发布的 RTMP specification v1.0对RTMP进行更深入的了解，本文不再赘述。
2.3.2 HLS
不管是RTMP还是HTTP-FLV，都逃不过一点——Flash。在12年Adobe发布RTMP specification v1.0时，本以为拿到流媒体金钥匙的Adobe未曾想未来是个HTML5的世界，一个不需要Flash的世界。
在09年三月iphone 3.0发布会上，苹果在新的操作系统宣传中添加了关于流媒体功能的微妙暗示。同年五月HLS协议正式发布。HLS协议的出现最初是为了解决苹果原生环境中的流媒体播放问题，这个协议可以方便的让Mac和iphone播放视频流而不依赖Adobe。依赖自己往往是最大的力量保障。
HLS全称HTTP Live Streaming，是一个由 Apple 公司实现的基于 HTTP 的媒体流传输协议。工作原理是通过将整条流切割成一个小的可以通过 HTTP 下载的媒体文件, 然后提供一个配套的媒体列表文件, 提供给客户端, 让客户端顺序地拉取这些媒体文件播放。
HLS协议包含三个部分：Server、Distribution 和 Client.
- 首先需要从导播端获取视频数据，通过其他支持推流的协议，将视频流传输到服务器上去。
- 其中Stream segmenter（流切片器）会从Media encoder（编码器）读取数据，然后将着这些数据一组相等时间间隔的小媒体文件。虽然每一个片段都是一个单独的文件，但是他们的来源是一个连续的流，切完照样可以无缝重构回去。
- 切片器在切片同时会创建一个索引文件(Index file)，索引文件会包含这些切片文件的引用。每当一个切片文件生成后，索引文件都会进行更新。索引用于追踪切片文件的有效性和定位切片文件的位置。切片器同时也可以对你的媒体片段进行加密并且创建一个密钥文件作为整个过程的一部分。
- Distribution相当于一个Http文件服务器，Client通过访问Distribution中的索引文件，便可以自动播放HLS流了。
图7：HLS 处理流程通过上述流程，用户拿到索引文件就相当于拿到了流媒体的钥匙，那么HLS生成的索引文件又是啥呢？让我们来解开他的神秘面纱——m3u8文件。
m3u8文件实际实质上是一个播放列表（playlist），其主要的两种形式为主播放列表（Master Playlist）和流媒体播放表（Media Playlist），也称一级索引和二级索引。
图8：m3u8文件内容可以看到主播放列表（一级索引）主要标识有带宽（BANDWIDTH）、视频分辨率（RESOLUTION）、音频编码格式（CODECS）以及二级索引路径；流媒体播放列表（二级索引）关键属性为切片持续时间（EXTINF）以及视频切片路径（按上图实例，该切片至少有9.009 9.009 3.003秒左右的延迟）；浏览器通过不断访问最新m3u8文件即可获得每个切片的地址并通过浏览器进行播放。
图9：直播 m3u8请求2.3.3 HTTP-FLV
HTTP-FLV本质上是RTMP在HTTP协议上的封装，同样都是传输的flv格式的数据，由于通过80端口通信，相比RTMP其穿透性更强。HTTP-FLV在本文中不再过多阐述。
2.3.4 三种直播协议对比及选型
三种直播协议的对比如下：
图10：三种协议对比根据三种常用的协议对比，在直播协议的选择上面可根据各自的特点进行选择——实时性要求（互动直播等）：RTMP/HTTP-FLV 稳定性要求（发布会等）：HLS
2.4 小结
本章对直播原理及常用的三种协议进行分析，供读者了解直播技术中涉及的基本概念。可能有些读者对枯燥的技术知识表示“抗议”，在此以物流系统对直播系统进行类比以供大家轻松愉快地理解：
相信大家平时都有网上购物习惯，举个例子：小明要在网上给女朋友买一个加热出现照片的定制杯子，他会经历网上下单，物流运输、驿站存取等步骤，而商家担任产品的制作需要经历杯子加工、打包、发货等步骤；
在这里商家就是主播，杯子就是原始视频，加上小明女朋友照片的杯子就是经过了处理工序，而打包就是编码封装按一定的规格给快递公司才给正常发货嘛，而发货就是相当于推流，此时物流公司就担任流分发的重任，将快递分发到各个驿站（CDN），而小明的快递便传递到了最近的驿站；
小明想起来要去拿快递了，于是凭借着取货码（拉流协议），去拿到这个杯子，这个提货的过程就相当于拉流，整个过程如下图所示：
图11：物流系统类比图相信通过这个形象的例子，大家一定对直播架构有了基本概念。
三、vivo官网发布会直播技术保障
3.1 发布会直播面临的挑战
本章主要介绍在vivo官网发布会直播过程中所遇到的问题，以及其一般性解决思路。新品发布会的影响力可想而知，特别是在发布会push发放节点以及发布会开始节点，会有大量的观众进入到官网直播间，此时的瞬时压力成为面临的第一道挑战，而随着发布会的进行，持续大流量也成为系统的隐患之一；当然由于发布会的特殊属性，一切都建立在不容出错的基础之上，保证发布会无异常发生。
可以看出发布会直播面临的问题实际上就是一个典型的高并发系统所面临的问题。而保护高并发系统的三大利器——缓存、降级、限流，便是发布会技术保障其中的一部分。
3.2技术保障
3.2.1 发布会缓存方案
正所谓网站性能优化第一定律就是考虑使用缓存针对发布会我们做了许多缓存优化方案。
细心的小伙伴会发现官网直播涉及到内容轮询获取，如直播人数、直播评论、点赞数等，而优化的第一步是调整轮询的时间间距，减小峰值QPS；而降低QPS后仍然会有大量请求过来，这时候作场景考虑，部分配置信息以及围观人数、点赞等对发布会主流程无决定性影响且实时性要求并不高，而采用单纯的redis集群会使得集群压力剧增，最初直接集群访问的模式已不再适应业务的发展，此时在技术层面考虑了这部分数据采用本地缓存进行存储。虽然会造成短暂的数据不一致的“损失”，但在对业务没有实质性影响的情况下，极大的提升了直播业务的稳定性。
图12：多级缓存演变示意图3.2.2 发布会降级方案
发布会场景的核心是保证直播音视频的正常播放，给用户了解咱们最新的产品。由于实际业务的需要与拓展，在发布会场景涉及到许多感知与互动元素，而如果因为这些业务功能导致发布会核心被拖垮显然得不偿失。所以在设计之初对这些业务设置了一些降级策略以防止这种情况的发生。在此举一种典型的场景以供大家理解进入直播页的第一道“工序”就是去查询直播的基础配置，而当访问量到一定程度通过观察日志发现部分请求超时甚至异常时，咱们就会开启强制熔断，后续查询就会走到fallback方法指向查询本地缓存中的内容，降低服务压力的同时也不会对用户的观看体验造成很大影响。
图13：熔断示意图虽然上述方案在实际发布会过程中均未触发，但未雨绸缪有备无患总是比出现问题再解决问题来的更加从容自然。
3.2.3 发布会限流方案
发布会直播评论抽奖作为典型流量场景，使用限流手段让部分抽奖评论排队等待，后续等处理完毕后再告知用户中奖信息。常见的限流算法有漏桶算法和令牌桶算法，而评论抽奖的特性是到时间段的瞬间有大量评论进入抽奖逻辑，限流既要考虑流量整形，又要考虑突发请求，令牌桶算法再适合不过。
图14：令牌桶算法示意图3.3 内容安全保障
由于面向公众，同时存在互动类玩法，内容安全性在发布会直播中也尤为重要，而在直播内容安全（即视频无敏感内容）的前提下，与用户侧相关的文字内容安全（涉黄、涉政、暴恐、违禁内容等）处理成为需要解决的一大问题。当然在内部谛听团队的支持下这一问题也迎刃而解，避免重复造轮子。
3.4 小结
通过本章作者希望大家理解直播的核心是给大家看视频听声音的，为了保证这一需求不出错的同时在上面进行一些拓展性的业务提升用户互动性需要面临诸多挑战，作为开发者需要意识到这些挑战并做好接受挑战的准备，为业务的提升打好基石。
四、写在最后
如今直播的业务存在形式多种多样，如发布会、游戏直播、教育直播、直播带货等，作者希望通过本文的介绍相信大家或多或少对直播技术有了一定的认知，直播涉及到的各个细节都有一个庞大的知识体系支撑，由于篇幅及个人知识经验有限，无法为大家呈现更多细节，有兴趣的读者可以以本文为参考对直播进行深入的了解。
下载文档
