[译] Facebook Live如何支持80w用户同时在线

---

写在前面：

这又是一篇翻译了好久的文章--花费时长其实并不久，主要是断断续续翻译先后算起来时长好久。这篇大概是目前翻译得最有共鸣的一篇文章-- 我大沙发厂也有live产品了呢。虽然量级不可比，文中提到的80w在线的流量盛况目前来讲也是个遥远的KPI,不过确实在产品迭代中也像文中同样踩了不少坑。做为产品在和讲师沟通配置的过程当中，对文末最后提的上传速度那一块的效果体验尤为感同身受。以及，依托于第三方服务来构建本身的产品终归须要不断试错和磨合--和恋爱同样。

最近还有一个关于live而产生共鸣的地方，想来也能够推荐一下，美剧《硅谷》。是的就是文中提到的那个魔笛手Pied Piper。具体点就是第二季大概最后几集里，在公司大概要宣布破产的时候，互怼基友Gilfoyle和Dinesh还有Jared为了撑住因 拆解秃鹰孵化的摄像头而失足坠落的工做人员的求救直播引来的凶猛流量致使已达极限的服务器 而不停敲代码甚至不顾它已经烧起来的盛况（这句话好长啊，不知道说没说清楚）。虽然情节为了剧情效果颇多不现实，但在我看来确实表明了一些geek精神还有创业维艰的事实。

---

原文地址 How Facebook Live Streams To 800,000 Simultaneous Viewers

---

译文部分：

懂得建立世界级服务产品的公司就像掌握核武器的国家同样很是少，Facebook就是其中之一。 而Facebook Live, 一款Facebook 新出的直播视频推流产品，就是这些世界级服务之一。

Facebook CEO 马克扎克伯格：

咱们作的这项重大的决定就是为了将咱们作的大量视频方向的尝试更多地转移到直播方向，由于直播是近来兴起的一种新模式；而不是已经在过去五年甚至十年都存在于网络中的视频…咱们已经进入了视频行业的黄金时代。若是你展望五年后的facebook,发现人们都经过直播来分享每日见闻，我一点也不奇怪。

若是你身处广告业务，想来最使人愉悦的就是永远不会中止的广告来源，而且不断扩张大量生成了吧。这就是Google 盈利的主要方式：在呈几何级增加的网页中插入广告。

Facebook Live 能展示如上述的能力体现之一就是一个45分钟的视频：两我的用橡皮筋切西瓜。达到了超过80万人同时在线的顶峰，有超过30万的评论。这就是一个拥有十亿五千万用户的社交网络能创造的病毒式传播效应。

做为对比，2015年超级碗一共有1.14亿的观众，有大概两百多万的用户观看直播 。 在2015年的电子娱乐展的 Twith 直播中，达到了84万的观看量。9月16号的共和党辩论达到了最高92.1万的同时在线观看人数。

因此对比来看，Facebook作直播最适合不过。须要注意的是，Facebook也可能会出现同一时段有大量直播正在进行的状况。

连线杂志有一篇文章引用了Facebook的首席产品负责人Chris Cox 的话：

• 有超过100人的直播产品团队（一开始只有12人左右，如今有超过150位工程师参与该项目）

• 须要支持百万以上的同步直播流而不崩溃

• 须要支持超过百万的在线观看人数，同时也要考虑全世界上不一样的设备适配以及服务商要求

Cox 说“最后发现这是个考验基础架构的难题”。

若是咱们能说一说怎么解决这个架构问题的细节，听起来不是颇有趣吗？ (为了解决这个问题)咱们真的很痛苦!但等等，咱们能够聊一下~

来自Facebook 流量团队（traffic team）的Federico Larumbe ，主要优化 Facebook 的CDN 处理能力 以及全球加载平衡系统，发表了一次精彩的演讲：Facebook Live 的演变和优化。 演讲中他分享了一些关于直播如何实现的细节。

如下是演讲内容的介绍。很是使人印象深入。

最开始

• Facebook 是一个容许用户实时分享内容的新功能（注意这里应该是指Facebook Live）

• 2015年4月以 Mentions 的移动客户端形式发布，当时只能名人使用，做为和粉丝交流互动的媒介

• 由此开始了一年的产品优化以及协议迭代

  • 他们最开始使用HLS(HTTP Live Streaming) ，这个协议在iPhone设备下被支持，同时也容许他们使用存在的CDN 架构

  • 同时也开始研究 RTMP（实时消息传输协议），一个基于TCP 的协议。会有一个视频流和音频流从手机上传到直播推流服务器

    • 优势： RTMP 在推流端和播放端之间有更低的点到点等待时间 。这在主播和观众常常互动的场景下很是有用。下降等待时间以及较少的延迟在体验上都是很是棒的改进

    • 缺点： 会请求整个架构资源由于它不是基于HTTP 协议。因而须要开发一个全新的 RTMP 代理。

  • 也在研究 MPEG-DASH (基于 HTTP 的动态适应串流）

    • 优势：对比HLS 节省了15%的空间

    • 缺点：容许自适应比率串流 ，编码质量会根据网络上传速度不断变化

  • 魔笛手数据压缩方法（开玩笑233333）

• 2015年12月在超过12个国家发布

视频直播有些不同—也形成了一堆问题

• 以前提到的橡皮筋切西瓜的直播的网络传输问题：

  • 一个陡增，几分钟内就达到了每秒超过100次请求并且持续增长直到直播结束

  • 传输又像碰到障碍同样一下彻底停下来

  • 换言之，整个数据访问很是迅速而又猛烈

  

• 视频直播和正常的录制视频不同：访问会形成大量的网络请求

  • 视频直播更强调参与性所以可能有三倍于录制视频的访问量

  • 视频直播会出如今新闻动态推送的顶部所以有更大的可能性被访问

  • 通知会被推送到全部页面上的粉丝，所以会有另一群用户会观看直播

• 迅速而又猛烈的网络访问请求会形成缓存和加载平衡系统方面的问题

• 缓存问题

  • 不少用户可能想同时观看直播视频，这就是经典的 惊群现象

  • 高访问请求会给缓存系统形成压力

  • 视频都是被分段放进一个二级文件中，高且频繁的访问会让缓存这些视频片断的服务器过载

• 全球加载平衡问题

• Facebook 有遍及全球的网络链接点（PoPs),因此直播的网络传输问题也是分布在全球的

• 问题就在于防止高访问量对网络链接点的访问过载问题

直播架构构建

如下就是一条直播推流如何由发起人（推流端）传到百万观众面前的过程：

• 发起人在手机上开启视频直播

• 手机发送一条RTMP 流到直播流服务器

• 直播流服务器解码传过来的视频并转码成多个比特率

• 每一个比特率的信息都会建立一个二级 MPEG-DASH 片断

• 这些片断都被存在一个数据中心缓存器中

• 在数据中心缓存器里，每一个片断又会被送到网络链接点中的缓存器里（一个 PoP 缓存）

• 在播放端，观众就收到了一个完整的直播视频

• 观众设备上的播放器会从 PoP 缓存中以每秒一次的速度抓取视频片断

一条直播推流又是如何传播扩散的？

• 在数据中心缓存器和众多 PoP 缓存器之间有一个聚合结点（multiplication point）, 用户会向 PoP 缓存器发送请求而不是数据中心，而同时有大量的 PoP 缓存器遍及全球。

• 另外一个聚合传播结点在每个PoP 内部

• 每个PoP 内部有两层：一层 HTTP 协议代理层，一层缓存层

• 播放端在HTTP 代理层请求视频片断，代理会检查改视频片断是否在缓存中，如有则直接从缓存中给出片断，没有则再向数据中心发送片断请求

• 不一样片断被存在不一样的缓存器中，这样能够减小不一样缓存宿主之间的负载平衡

避免数据中心出现惊群现象

• 当全部用户同时请求了同一个视频片断会发生什么？

• 若是该请求的视频片断不在缓存中，则会为每个用户向数据中心再发送一条请求

• 请求合并。请求的数量会经过向PoP 缓存添加请求合并而减小。只有第一条请求会被发送给数据中心，其它请求则会被挂起直到第一个响应到达，数据就会被送到全部用户播放端

• 新的缓存层会被加到代理中以免热服务器问题

• 全部的用户请求会被发送到一个缓存主机中等待视频片断，这样可能致使负载太重

• 代理会增长一个缓存层，只有第一条请求会被代理发送到缓存器，全部接下来的请求则会直接被代理处理

PoPs 仍处于危险之中 —随时须要处理全球性负载均衡问题

• 因此数据中心已被避免发生惊群问题，可是PoP 节点仍在危险之中。直播的问题在于流量陡增太迅速PoP节点会在达到负载均衡前就已过载。

• 每个PoP节点都有一个限制服务器数量和链接点数量。如何避免直播时的迅猛访问对PoP形成过载？

• 一个叫 Cartographer的系统会把子网与PoP映射起来。这个系统用来处理每一个子网和每一个PoP节点之间的延迟。这是一种延迟处理方式

• 每个PoP的加载都会被处理，每个用户的请求都会被发送到有足够容量的PoP节点中。在每个代理中都有计数器来统计他们收到的加载数量。这些计数器的统计会让咱们了解到每个PoP的负载状况

• 因此又有了关于负载容量限制的考虑和最小化延迟的优化问题

• 在控制系统内部接收和处理也一样存在延迟

• 他们将窗口的加载处理时间从一分半缩减到3秒钟—仍存在3秒钟延迟

• 解决问题的关键是预处理（上述提到的全部的须要处理的）加载时间

• 经过注入容量预估器来推断内部加载时间以及每个PoP传输加载时间还有返回后的加载时间

  • 若是当前的的加载时长在上升，预测器是如何能判断加载时间会减小？

  • 三次样条插值函数（Cubir splines)用来描述插入函数

  • 一阶导数和二阶导数会先被执行，若是显示速度为正值则说明加载会增长。若是加速度为负值则意味着速度在减小并最终减为零并开始减速。

  • 三次样条插值函数比线性函数更能预测复杂的网络流量类型

  • 避免抖动，这类插入函数同时也避免了传输抖动问题

  • 接收和处理的延迟意味着在对旧数据的处理，插入函数能减小出错，更精准预测和减小抖动，这样能使负载更接近容量目标

  • 当前预测时间是基于最近三次处理的间隔时间（每次间隔有30秒），几乎是瞬时加载

测试

• 须要测试PoP的过载状况

• 一个模拟直播实时流量的加载测试服务会经过PoP节点分发到全球

• 可以模拟10倍于正常状况下的负载

• 可以模拟一位观众不停请求视频片断的状况

• 测试系统帮助复现和修复容量预估器会出现的问题，修正一些参数值设置，以及鉴别缓存层可能出现的惊群现象

上传可靠性

• 实时上传视频很是有挑战性

• 以大概有100-300 Kbps 的有效带宽为例

• 音频大概须要64 Kbps 的有效上传带宽

• 标清视频须要大概500 Kbps

• 移动设备上采用适应性编码来调整音频+视频上传时码率不足的问题。编码视频时会根据网络上行带宽来调整上传码率

• 经过处理 RTMP 协议链接时的上传字节数来自动调节手机上的上传码率，通常是经过读取单位上传时间间隔内获取的字节数的平均速率

将来的方向

• 研究推流方向的优化而非拉流，在视频片断被PoP节点请求前来平衡 HTTP/2 协议的推流效率

相关文章

• hacker news

• 为何扎克伯格全力投入视频直播方向

• 链接世界：facebook的网络架构一瞥

• Gamoloco 获取到的1476093 个频道的视频直播数据