Facebook 直播如何撑起瞬间 80 万人的流量?

【伯乐在线小编注】:此文来自合作网站 Inside 硬塞,他们是台湾网站,所以本文中有些技术术语和大陆不一样。

Screenshot 2016-07-01 17.39.16

知道怎么打造世界级分布式服务(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 5 收藏 2 评论

相关文章

可能感兴趣的话题



直接登录
最新评论
跳到底部
返回顶部