原创译文|Facebook如何实现80万人同时在线观看直播

现在只有极少数公司知道如何提供世界跨越式分布服务，这些公司的数量甚至比当今拥有核武器的国家还少。Facebook就是这少数中的一个，它的新视频直播流媒体产品Facebook Live就是跨越式分布服务的代表。

Facebook CEO 马克·扎克伯格：

我们最终决定将视频服务的重心转向直播，因为直播是一种新兴的模式，不同于过去五到十年的网络视频模式，我们即将进入视频发展的黄金阶段。如果时间快进五年，人们在Facebook上看到的大部分内容都可能会以视频的形式呈现。

Facebook直播的强大技术体现在一段45分钟的视频中，视频里两人用橡皮筋给西瓜施压最后使其爆炸。这段视频最大观看人数高达80万，并有超过30万条评论。这一惊人数据是基于Facebook15亿用户基础上的。

2015年美国超级碗播出时，有11.4亿人观看了比赛，约236万通过直播观看比赛。在Twitch平台上，2015年E3游戏盛会中最高观看人数达到84万。在9月13日共和党辩论时，直播观看人数一度达到92.1万。

在当前科技条件下，在直播领域，Facebook也是遥遥领先的。不容忽视的是，Facebook同时在进行着很多直播节目。

Facebook产品总监Chris Cox：

Wired中一篇文章援引Facebook产品总监Chris Cox的话，称Facebook有超过100人的部门在负责直播（一开始只有不到12人，现在已经发展到拥有150个工程师）。

Facebook需要为数百万个同时进行的直播提供服务而不出现故障，同时还要为观看直播的数百万个观众提供支持，而且还要处理不同设备和服务商之间流畅连接的问题。Cox说“这确实是个很棘手的技术问题，需要强大的基础设施。”

大家是不是很好奇这些基础设施的问题是如何解决的呢？

Facebook流量团队的Federico Larumbe一直在研究一个超高速缓存软件，可以为Facebook内容分发网络和全球负载均衡系统提供动力，他做了一个精彩的演讲。演讲中他详细介绍了直播是如何实现的。这篇演讲确实非常精彩。

直播技术的起点

Facebook有一项新功能，就是允许用户实时分享录像视频。直播服务开始于2015年4月，起初只有名人才能通过Mentions应用享受这一服务，主要用于与他们的粉丝互动。随后一年，这项服务产品得到了提升，产品协议也发生变化。他们开始借助流媒体和超文本传输直播，并得到了iPhone的支持，允许他们使用CDN结构。与此同时，Facebook开始研究基于传输控制协议的实时消息传送协议（RTMP，Real-Time Messaging Protacol），可以从手机传送一条视频直播或音频直播至直播服务器。

优点：对于那些主播与看客来说，RTMP具有更低的风险。与传统播放方式不同，人们在直播平台上可以互相交流沟通。低风险低延迟，用户体验就得以提升。

缺点：因为原设备不是基于超文本传输协议的，所以需要一整套新的结构。新的实时消息传送协议需要经过一段时间发展才能形成规模。

Facebook同时还研究MPEG-DAH （HTTP的动态自适应流媒体）

优点：和流媒体相比，它能节省15%的空间。

缺点：它对比特率要求较灵活。根据网络吞吐量的不同，编码质量也会出现差别。

直播的视频是多种多样的，而此引发的问题

直播会经历西瓜式的流量模式:开始后会经过一个急剧上升的过程，几分钟以后，每秒就有超过100条请求，并且持续增长，直至直播结束，之后流量会急剧下降，换句话说，流量变化是非常剧烈的。

直播和一般的视频节目不同，它会产生十分极端的流量模式。直播节目更能吸引人们的注意，因此通常观看人数是普通视频的3倍还多。动态消息中排在靠前位置的直播通常会有更多人观看，而且关于直播的通知会通过每个页面发给所有粉丝，这样一来，观看视频的人数就会更多。

然而极端的流量会导致超高速缓存系统和全球负载平衡系统方面出现问题:

超高速缓存问题

在同一时间有很多人都可能想看直播视频。这是经典的惊群效应问题。极端流量模式对超高速缓存系统施加了非常大的压力。视频被分解成一秒一秒的文件，当极端流量出现时，缓存这些文件的服务器就会出现超负荷问题。

全球负载均衡问题

Facebook在世界各地都有入网点，流量分布在世界各个国家。所以Facebook需要解决的问题是如何防止入网点超负荷。

整体架构

直播内容是如何传送到数百万观众那里的呢?主播在他们的手机中开始视频直播。手机将一个RTMP流视频发至直播服务器。服务器解码视频，然后转码成多种比特率。接着，每一种比特率都产生一组一秒的MPEG-DASH片段。这些片段储存在数据缓存处理中心，然后发送到入网点的缓存硬盘中。观众端就可以收到直播节目，他们设备里的播放器以每秒一个的速度从入网点缓存中提取片段。

运作的原理是什么？

在数据缓存中心和众多入网点缓存之间，存在一种乘法关系。用户进入的是入网点缓存而非数据中心，这些入网点缓存是分布在世界各地的。

另一种乘法关系是在入网点内发生的。入网点有两个层面：代理服务器层面和缓存层面。观众从代理服务器中发出提取片段的请求。服务器检查缓存中是否存在片段。如果有存在，片段就会发送给观众，如果没有，这个请求就被发送至数据中心。不同的片段存放在不同的缓存硬盘中，这样一来，不同的缓存主机之间就能达到负荷均衡。

在惊群效应下保护数据中心

如果所有的观众都在同一时间要求提取同一片段，会出现什么情况呢？如果该片段不在缓存中，每个观众的请求都会被送往数据中心，所以需要对数据中心进行保护。

请求合并

通过将请求合并到入网点缓存中，请求的数量就会减少。只有第一个发出的请求会发往数据中心。其他的请求暂时不处理，直到第一个请求得到回复，然后数据就会发往各个观众手里。现在代理服务器中又增加了缓存层，以防止出现热服务器问题。如果所有有关的请求都被发往一个缓存主机，等待片段发回，这样就可能会使主机超负荷。

全球负载均衡解决方案

虽然数据中心得到了很好的保护，防止出现惊群效应问题，但是入网点依然存在风险。直播流量可能太过巨大，以至于在入网点的负载检测到达平衡之前就出现超负荷的情况。

每个入网点的服务器和连通性是有限的。如何能够防止入网点出现超负荷的情况呢？一个名为Cartographer maps的系统可以很好地解决这一问题。它能测量每个网络和入网点的延迟，即时延测量。每个用户都被送往最近的入网点，每个入网点的负载都可以得到测量。在服务器中有计数器来测量他们接受的负荷大小。这些计数器的数据汇集起来之后，我们就知道每个入网点的负荷了。

容量约束和减小风险的最优化问题

因为控制系统的关系，在测量和行动时会出现延迟。他们将负荷测量窗口从90秒改到3秒。这个问题的解决方案就是一定要在负荷发生前就预测出来。将一个容量估量器安置到其中，通过之前的负荷和当前负荷推断出每个入网点的未来负荷。

估量器是如何预计负荷？如果当前负荷增长，它有下降的可能吗？

三次样条函数比线性插值函数能预测更多复杂的流量模式，我们运用三次样条函数解决插值函数，先得出一阶导数和二阶导数。如果速度为正，负荷就上涨。如果加速度为负，意味着速度减小，最后减小为零。

避免震荡

插值函数还可以解决震荡问题。

测量和反应的延迟是因为数据过期，插值函数可以减少失误，进行更准确预测，并且减少震荡。如此一来，负荷就会更加接近容量目标。目前的预测是基于最后的三个间隔，每个间隔30秒，几乎瞬间就超载了。

翻译：灯塔大数据