公告：facebook刷赞网站--facebook加播放量网站
（点选下方社会公众号，可加速高度关注）
英语：Todd Hoff
翻译者：Inside - Mia
镜像：http://www.inside.com.tw/2016/07/01/how-facebook-live-streams-to-800000-simultaneous-viewers
【庞德公新浪网小布季谢】：该文源自密切合作中文网站 Inside 硬塞，她们是台湾地区中文网站，因此责任编辑中很多控制技术名词和内地不那样。
晓得是不是打造出国际级肩蝠（distributed service）的子公司，可能将比保有核武器的北欧国家还少。Facebook不但是当中的翘楚，而它新面世的现场直播机能是几项肩蝠。
Facebook总干事 Mark Zuckerberg 就曾说过：
我们做了重大决定，是把在影片的努力转而聚焦到现场直播上，因为它是接下来的新格式，而非已经存新浪网上5 — 10 年的那种影片。我们正进入影片的新黄金年代，我相信往前快转5 年，很有可能将Facebook 上使用者每天分享的内容几乎都是影片。
如果你在广告业，还有什么比没有尽头、一直在成长，而且免费产生的内容更适合拿来放广告呢？这就像Google在网路指数成长时，为各中文网站提供广告所开拓的市场那样。
Facebook的现场直播控制技术坚强，就像BuzzFeed在Facebook现场直播用橡皮筋爆西瓜，最高达80万人同时新浪网上收看，共有30多万条留言。这也是在15亿使用者的社群网路上才看得到的病毒传播效应。
作为参考， 2015 年的超级杯共有1.14 亿观众收看，平均有236 万人在看现场直播；2015 的E3 电玩展则同时有84 万人在Twitch 上收看；而9 月16 日的共和党辩论最多有92.1 万人同时在收看现场直播。
与此同时， Facebook 上还有其他大量的现场直播正在发生。那么Facebook 到底投注了多少资源在现场直播上呢？
根据Facebook的产品长Chris Cox在Wired报导上提到：
有超过百人在现场直播底下工作。一开始在12 人左右，到现在已经有超过150 名工程师。
要能同时处理上百万条现场直播而不当机。
要能负担一条现场直播上的数百万位观众，还要在全球不同的装置和网路提供商间无缝同步播出。
Cox 也承认「结果基础架构的问题真的不好解决。」
要是我们能晓得这些基础问题是是不是解决的，应该会很有趣。
Facebook流量团队的 Federico Larumbe，就在Facebook控制技术部落格上发表了《Scaling Facebook Live》，里面提到了现场直播运作的细节。
原文相当精彩，重点节录如下：
起源
Facebook 开了一个新机能，让使用者能分享即时影片。（注意，在这里现场直播对Facebook 来说是一个机能而已）
2015 年4 月只能透过Mention app 现场直播，而且限定名人专用。
随后便展开长达一年的改进与协定的变动。
优点：比HLS 省15% 的空间。
优点：自动调整传输率，会根据网路状况改变传输品质。
优点：RTMP 在现场直播主和观众间点对点的延迟较低，在互动式的现场直播上特别有帮助。降低延迟也能提升整体的体验。
缺点：因为不是基于HTTP，因此需要全新的架构。要规模化一定要架个新的RTMP 代理。
她们从HLS （HTTP Live Streaming）开始，iPhone 可支援，而且她们也可以使用现有的内容传递网路。
同时开始研究 RTMP (Real-Time Messaging Protocol，即时讯息传送协定) ，这是一种基于TCP的协定。分别有一条音讯串流和视讯串流从手机传送到现场直播伺服器。
另外也研究了 MPEG-DASH（基于HTTP的动态与适应性媒体串流）
2015 年12 月在数十个北欧国家展开服务。
现场直播影片很特别，也带来许多问题
拿一开始的西瓜影片流量表现为例：
在一开始流量上升得很快，数分钟内就达到每秒超过100 个请求，直到影片结束都持续上升。
影片一结束流量就直直落。
简而言之：瞬间流量很大。
现场直播影片和一般影片不那样：它会产生瞬间流量。
现场直播影片和观众的连结更深，因此通常观看次数比一般影片多3 倍。
现场直播影片会被推到资讯墙最下方，因此被看到的机会也比较高。
专页的所有粉丝都会收到现场直播通知，又吸引到一批可能将会来看影片的观众。
瞬间流量会对cache （暂存）系统和负载平衡系统造成问题。
Cache 的问题
很多人同时想要收看你的现场直播，导致经典的「惊群效应」（Thundering Herd problem），大量等待中的处理程序同时被唤醒，却只能一次处理几项。
大量瞬间流量会对cache 系统造成压力。
一部串流影片被分割成很多一秒的小档，流量飙高时，暂存这些分割档的伺服器可能将会超载。
全球负载平衡系统的问题
Facebook 在全世界都有分布PoP ，Facebook 的流量是分散到全世界的。
因此挑战在于避免瞬间流量灌爆当中一个PoP。
整体架构
这里是现场直播如何从现场直播源散布给上百万观众的过程。
现场直播主从手机开了一条现场直播。
手机传了RTMP 串流到现场直播伺服器。
现场直播伺服器解码影片后转换成各种传输率的影片。
每种传输率都创造一组 MPEG-DASH 的连续数个一秒钟片段。
这些片段都存在资料中心的暂存里。
Cache 暂存从资料中心传送到各个PoP 暂存。
观众收到现场直播。
观众手机上的播映器以每秒一次的频率开始从PoP 接收片段。
要是不是规模化？
从资料中心到PoP，端点数会增加非常多。使用者会存取PoP暂存而非资料中心暂存，而PoP是分布在全世界的。
另外每个PoP内部还会再细分。
每个PoP内部都分成两层：一层是HTTP代理，另一层是暂存。
观众从HTTP 代理请求片段。代理会检查片段有没有在暂存里面，有的话就会回传片段，没有的话就会往回向资料中心请求片段。
不同的片段存在不同的暂存，因此能让不同的host负载平衡。
保护资料中心免于惊群效应
所有观众同时要求同一个片段会发生什么事？
如果片段不在暂存里，每个观众都会向资料中心发出一笔请求。
Request Coalescing（回应联合）。透过在PoP暂存增加request coalescing来减少请求的数量。只有第一个请求会传到资料中心，其他的请求会被拦下，直到第一个请求到了资料中心，然后资料回传到所有观众手上。
代理会加上一层新的暂存，来避免伺服器过热。
所有的观众会被送到一台暂存host 去等待接收，这可能将会导致host 过热。
代理加了一层暂存层。只有第一个到代理的请求会成功要到暂存。其他的请求会直接由代理处理。
PoP 还是身陷险境：靠全球负载平衡来拯救
因此资料中心免于惊群效应的问题，但是PoP 还是暴露在危险中。问题在于，PoP 的负载衡量结果到达负载平衡器之前，流量可能将就已经灌爆PoP 了。
每个PoP 都有限制伺服器和连线的数量。瞬间流量要如何不灌爆PoP？
一个叫做Cartographer 的系统会描绘网际网路到PoP 的子网路。它会衡量每个子网路和PoP 间的延迟。
测量每个PoP 的负载后，每位使用者就会被传送到附近能够负载的PoP 。代理有计数器会记录她们收到多少负载。这些计数会累计，因此我们可以晓得每个PoP 的负载。
现在现在出现了一个最佳化问题，我们要在负载限制下同时降低延迟。
用控制系统，可以分为测量的延迟和反应的延迟。
她们把负载测量间隔从1.5 分钟缩短到3 秒钟，但是这样仍旧有3 秒钟的空窗。
解决办法是在发生之前先预测负载。
依据先前及当下的负载，负载估计器会预测未来的负载量。
如果现在的流量是上升，预测器要是不是才能预测到流量下降？
在插入函式使用三次样条函数（Cubic spline）。
利用一阶和二阶导数。如果速度是正的，那负载量就会增加，如果加速度是负的，就表示速度下降，最后负载会开始降低。
三次样条函数能预测比线型函数更复杂的流量模式。
避免波动。这个插入式也可以解决波动的问题。
测量和反应的延迟，表示会依据不够及时的数据做决定。插入式函数能减少错误，让预测更准确，并降低波动。因此负载量能更接近目标。
现在是根据过去的三个区间来做预测，每个区间间隔30 秒。几乎是等于即时的负载量。
测试
首先你要能让一个PoP 过载。
负载测试分散在全球的PoP 上，好模拟现场直播的即时流量。
要能模拟目前负载量的10 倍。
要能模拟一位一次请求一个片段的观众。
这个系统能找出并修补负载估计器的问题、调整参数，并验证暂存层能否克服惊群效应。
上传的稳定性
即时上传影片很有挑战性。
举一个频宽介于100 — 300 Kbps 的上传为例。
音讯总共要64 Kbps。
标准画质的视讯共要500 Kbps。
利用手机上的适应性编码来调整音讯加视讯的不足。影片的传输率编码会根据网路频宽调整。
手机端会测量RTMP 上传位元，来决定上传的传输率，并且根据上个区间的平均来加权。
未来的方向
研究推送机制，而非request-pull 机制。在请求片段之前就利用HTTP/2 推送至PoP。
更多推荐请看《值得高度关注的控制技术和设计社会公众号》
当中推荐了包括控制技术、设计、极客和IT相亲相关的热门社会公众号。控制技术涵盖：Python、Web前端、Java、安卓、iOS、PHP、C/C++、.NET、Linux、数据库、运维、大数据、算法、IT职场等。点选《值得高度关注的控制技术和设计社会公众号》，发现精彩！
