关于java:发布会直播技术及业务实践

一、背景

随着直播行业的近年来的倒退，直播技术现已日趋成熟。本文次要介绍目前支流的直播技术原理，以及在直播在发布会场景下的利用以及过程中遇到的问题及解决方案。

二、直播原理

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 视频推流端

 视频推流端工作流程次要分为 四步：

1. 采集：主播 / 导播通过摄像机、手机等录制设施进行音画采集；
2. 解决：在导播台将原始音画进行肯定的解决如美颜、加水印、滤镜等；
3. 编码和封装：当原始视频被处理完毕后通过编码器如 H.264、H.265 等进行编码，将宏大的音视频源文件压缩，并通过封装将编码好的媒体内容封装为标准的媒体文件格式如 AVI、MOV、MPEG 格等；编码的核心思想是去除媒体信息中的冗余，包含：空间、工夫、编码、视觉等；而封装的意义就好比用何种货车去运输货物（媒体内容），让播放变得简略。
4. 此步骤对流媒体传输有着至关重要的作用，波及标准和常识也非常丰盛，有趣味的同学能够寻找相干文章进行理解，在此不进行具体阐明。
5. 推流：最终通过推流工具将该流媒体向服务器推送，“推”一动词形象地形容了主播被动将流推送至服务器的过程。到此步被成为直播的第一里程碑。

2.2.2 流媒体服务器

流媒体服务器是流媒体利用中的外围零碎，是运营商向用户提供流媒体服务的要害平台。

当主播应用推流软件将流媒体推送至各种流媒体服务器之后，流媒体服务器能够将获取到的媒体内容进行增强、转码等各式各样的操作，同时服务器可依据解析进去的媒体内容进行额定的业务拓展如平安审核等，最终服务器会将解决好的媒体内容以适合的流媒体协定将流媒体内容传输至 CDN，观看用户端便能够随时拉取媒体内容进行播放。

2.2.3 播放端

也称拉流端，用户可应用各种流媒体播放 app 拉取想要获取的信息。

播放端的 步骤 如下：

1. 拉流：通过播放 app 并选取适合的拉流协定进行拉取媒体内容；
2. 解复用：将处于“多媒体文件格式”的流解复用，成为“视频编码格局”和“音频编码格局”，艰深点说就是把“音视频信号源”分流出独自的“视频数据”和“音频数据”。（如.FLV 解复用后失去 H.264 视频数据和 AAC 音频数据）。
3. 解码：硬解码（GPU 解码 +CPU 辅助）或软解码（CPU 解码）将解复用失去的音视频数据进行解码，解码后失去 YUV 或 RGB 格局的视频以及 PCM 格局的音频。
4. 音画同步并输入播放：解码后终端会执行音画同步的操作，并将同步后的音频输送至音频设备进行播放，视频通过输送至视频输出设备进行播放。

通过以上几个步骤，用户端就可能顺利的开始播放直播啦。

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 小结

通过本章作者心愿大家了解直播的外围是给大家看视频听声音的，为了保障这一需要不出错的同时在下面进行一些拓展性的业务晋升用户互动性须要面临诸多挑战，作为开发者须要意识到这些挑战并做好承受挑战的筹备，为业务的晋升打好基石。

四、写在最初

现在直播的业务存在模式多种多样，如发布会、游戏直播、教育直播、直播带货等，作者心愿通过本文的介绍置信大家或多或少对直播技术有了肯定的认知，直播波及到的各个细节都有一个宏大的常识体系撑持，因为篇幅及集体常识教训无限，无奈为大家出现更多细节，有趣味的读者能够以本文为参考对直播进行深刻的理解。

作者：vivo 官网商城开发团队