Facebook 直播如何撑起瞬间 80 万人的流量？
【伯乐在线小编注】：此文来自合作网站 Inside 硬塞，他们是台湾网站，所以本文中有些技术术语和大陆不一样。
知道怎么打造世界级分布式服务（distributed service）的公司，可能比拥有核武的国家还少。Facebook不仅是其中的佼佼者，而它新推出的直播功能就是一项分布式服务。
Facebook执行长 Mark Zuckerberg 就曾经说过：
我们做了重大决定，就是把在影片的努力转而聚焦到直播上，因为它是接下来的新格式，而非已经存在线上5 — 10 年的那种影片。我们正进入影片的新黄金年代，我相信往前快转5 年，很有可能Facebook 上使用者每天分享的内容几乎都是影片。
如果你在广告业，还有什么比没有尽头、一直在成长，而且免费产生的内容更适合拿来放广告呢？这就像Google在网路指数成长时，为各网站提供广告所开拓的市场一样。
Facebook的直播技术坚强，就像BuzzFeed在Facebook直播用橡皮筋爆西瓜，最高达80万人同时在线上收看，共有30多万条留言。这也是在15亿使用者的社群网路上才看得到的病毒传播效应。
视频：https://www.facebook.com/BuzzFeed/videos/10154535206385329/
作为参考， 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 （HTTP Live Streaming）开始，iPhone 可支援，而且他们也可以使用现有的内容传递网路。
- 同时开始研究 RTMP (Real-Time Messaging Protocol，即时讯息传送协定) ，这是一种基于TCP的协定。分别有一条音讯串流和视讯串流从手机传送到直播伺服器。
- 优点：RTMP 在直播主和观众间点对点的延迟较低，在互动式的直播上特别有帮助。降低延迟也能提升整体的体验。
- 缺点：因为不是基于HTTP，所以需要全新的架构。要规模化一定要架个新的RTMP 代理。
- 另外也研究了 MPEG-DASH（基于HTTP的动态与适应性媒体串流）
- 优点：比HLS 省15% 的空间。
- 优点：自动调整传输率，会根据网路状况改变传输品质。
- 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。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
