Facebook 是如何支持 80 万并发视频流直播的

具备构建横跨全球的分布式服务能力的公司寥寥无几，甚至比拥有核武器的国家还要少。然而，Facebook 就是这样的一个公司，它的视频流直播系统 Facebook Live 就是一个横跨世界的分布式服务。Facebook 的 CEO Mark Zuckerberg 说：

我们做了一个重大决定，把更多的精力集中在视频直播上。因为直播是一种新兴的方式，跟过去五年甚至十年的那些离线视频不一样……我们正迎来视频的新黄金时期。如果把时间快进五年，人们在 Facebook 上看到的和他们每天分享的大部分内容都是视频，这对我来说一点也不惊奇。

如果你身处广告行业，还有什么比获得源源不断的可作为广告载体的内容更能激动人心？这些内容不拘一格地出现，持续增长，永不停息。谷歌在这上面打起了如意算盘，开始把广告业务的重心压在呈指数级增涨的Web 上。

能够体现Facebook 在流视频方面具有强大能力的例子，当属那个两人使用橡皮圈撬开一个西瓜的视频。这个视频时长45 分钟，高峰时段有80 万人同时在线观看，这些观众还给出了30 万份评论。对于一个拥有15 亿用户的社交网络来说，这样的并发量可以说已经达到了病毒级规模。

2015 年的 Super Bowl（美国国家美式足球联盟年度冠军赛）有 1 亿 1 千 4 百万观众，其中大概有 236 万观看的是视频直播。在 2015 年的 E3 游戏展期间，Twitch 直播系统高峰期用户达到 84 万。9 月 16 日的共和党辩论在高峰时有 92 万 1 千人同时在线观看直播。

这么看来，Facebook 也已经是名列前茅了。这里要注意的是，Facebook 在同一时间还要处理其它大量的视频流。

有一篇文章引用了 Facebook 首席产品官 Chris Cox 的话，他说 Facebook：

• 有超过100 人同时工作在 Live 项目上（刚开始只有 12 个人，现在有 150 多人）
• 希望并发直播流的服务能力可以达到百万级别
• 希望可以做到单个流支持百万并发用户，还能无缝地支持跨设备、跨地域的视频流服务

Cox 说“我们发现这是一个非常具有挑战性的基础设施问题”。如果把我们解决这个问题的细节公之于众应该会很有趣的吧？天啊！不过等等，我们会这么干的！

Federico Larumbe 来自 Facebook 流量团队，他负责的缓存系统支撑着 Facebook 的 CDN 和全局负载均衡器。他为我们带来了“横向扩展 Facebook Live ”的出色演讲，分享了 Live 的一些工作细节。

下面是我对这次演讲做的笔记，它真的令人印象深刻。

最初的故事

• Live 是一个可以让人们实时分享视频的新项目。
• Live 在 2015 年 4 月份启动，当时只能通过 Mentions 使用，作为少数高端人士与他们粉丝之间的互动工具。
• 在之后的一年里，产品不断改进，协议也在迭代更新。
  • 他们开始使用 HLS ，也就是 HTTP Live Streaming。iPhone 开始支持 Live，并允许他们使用现有的 CDN 架构。
  • 同时对 RTMP （Real-Time Messaging Protocol）进行调研，RTMP 是一个基于 TCP 的协议。手机端分别有一个视频流和音频流被发送到 Live Stream 服务器。
    • 优点：RTMP 缩短了从广播者到观看者之间的延迟，这个对广播来说意义重大。减少几秒钟的延迟，从用户体验方面来说就是一个很大的改进。
    • 缺点：需要全新的架构，因为它不是基于 HTTP 的。需要开发新的 RTMP 代理，这样才能大规模使用。
  • 同时调研了 MPEG-DASH （基于 HTTP 的动态自适应流）。
    • 优点：相比 HLS，它可以节省 15% 的空间。
    • 缺点：它支持自适应比特率，编码质量取决于网络的吞吐量。
• 2015 年 12 月，在多个国家启动了该项目。

不同的直播视频引起的问题

• 之前提到的撬西瓜视频的流量模式：
  • 刚开始增涨很快，在几分钟内就超过每秒 100 个请求，然后持续增涨，直到视频结束。
  • 然后流量呈断崖式下降。
  • 换句话说，流量的形状就像一个尖刺。
• 直播视频跟一般的视频不一样，它的流量模式呈尖刺状。
  • 直播视频更吸引人，比一般视频会多出3 倍以上的浏览量。
  • 直播视频会出现在显眼位置，更有可能被浏览到。
  • 网站的忠实用户会收到通知，所以有更多的人可能会看到视频。
• 尖刺流量模式会给缓存系统和负载均衡器带来一些问题。
• 缓存系统问题
  • 有可能很多用户同时观看视频直播。这样会造成惊群（ Thundering Herd ）问题。
  • 尖刺流量模式会给缓存系统带来压力。
  • 视频按秒分段存储，缓存视频分段的服务器有可能在流量高峰时过载。
• 全局负载均衡问题
  • Facebook 的 PoP（ Point of Presence ）服务器分布在世界各地，流量通过全局进行分发。
  • 如何防止高峰流量拖垮 PoP 是个具有挑战性的问题。

全局架构

视频直播流从主播端到观众端的流程是这样的：

• 主播在他们的手机上发起一个视频直播。
• 手机把 RTMP 流发送到 Live Stream 服务器上。
• Live Stream 服务器对视频流进行编码并转成多种比特率。
• 服务器为每种比特率持续地生成 MPEG-DASH 分段。
• 分段被存储在数据中心的缓存里。
• 分段从数据中心的缓存转发到 PoP 的缓存里。
• 观众端接收直播流。
• 观众端设备上的播放器以一定的速率从 PoP 缓存里获取分段。

如何横向扩展

• 在数据中心缓存和 PoP 缓存之间存在一个多路分发点。用户访问的是PoP 缓存，而不是数据中心缓存，而且有很多 PoP 缓存分布在世界各地。
• 在每个 PoP 里也有多路分发机制。
  • PoP 内部被分为两层：一层是 HTTP 代理，一层是缓存。
  • 用户向 HTTP 代理请求分段，代理检查分段是否已经在缓存里，如果是，就返回分段，否则请求会被发送到数据中心。
  • 不同的分段被存储在不同的缓存里，这样有助于在多个缓存主机间进行负载均衡。

避免数据中心出现惊群效应

• 如果所有用户同时对同一个分段发起请求会出现什么情况？
• 如果分段不在缓存里，所有请求都会被发送到数据中心。
• 合并请求。在 PoP 缓存里使用合并请求可以减少发送请求的数量，这样只有一个请求会被发送给数据中心。其它请求会等待第一个请求返回的响应，然后把数据返回给用户。
• 增加一个新的缓存层，避免出现热点服务问题。
  • 所有用户向的请求都发给同一个主机会造成该主机过载。
  • 在代理里增加缓存层。只有第一个请求会访问到缓存，代理会处理剩下的请求。

PoP 还存在风险，需要全局负载均衡来救场

• 数据中心的惊群问题得到了解决，但 PoP 仍然存在风险。Live 存在的一个问题是，在 PoP 达到负载均衡器的负载指标之前，高峰流量已经让 PoP 发生过载。
• 每个 PoP 的服务器数量和连接带宽都是有限的。如何避免 PoP 在高峰时发生过载？
• 一个叫 Cartographer 的系统把子网跟 PoP 映射起来，它会对每个子网和 PoP 之间的延时进行监测。
• 在知道每个 PoP 负载的情况下，用户请求会被发送到距离最近的可用 PoP 上。代理有一个负载计数器记录了它们的负载情况。通过收集这些计数器我们就可以知道每个 PoP 的负载情况。
• 现在出现了对 PoP 处理能力的约束和最小化延迟的优化问题。
• 控制系统在收集指标和作出反应方面存在延时。
• 他们把指标收集时间从一分半钟减少到 3 秒，不过 3 秒仍然是延迟。
• 解决方案是对负载进行预测。
• 他们实现了一个负载评估器，通过前一个负载和当前负载来推断后面的负载。
  • 如果当前负载是增加的，那么评估器如何能推断下一个负载会减弱？
  • 他们使用了三次样条插值（ Cubic Spline Interpolation ）功能。
  • 先获得第一个和第二个导数，如果速度是正数，说明负载在增加。如果加速度是负数，那么说明速度在下降，并最终变成零。
  • 三次样条插值可以预测更复杂的流量模式，不仅仅是线性模式。
  • 避免振动。
  • 插值功能同时解决了振动问题。
  • 指标收集和反应出现延迟说明数据已经过时。插值会减小误差，预测更准确，同时减少振动。这样负载就可以接近预设值。
  • 目前的预测是基于前三次的时间间隔，每个间隔 30 秒，所以得出的结果几乎是实时的。

测试

• 想办法让 PoP 过载。
• 构建一个负载测试服务，为 PoP 模拟直播流量。
• 模拟 10 倍于真实数据的负载。
• 模拟每次请求一个分片的客户端。
• 这个测试系统有助于发现和修补负载评估器的漏洞，用以调整配置参数，并验证用于解决惊群问题的缓存层是否工作正常。

上传的可靠性

• 实时上传视频是一个挑战。
• 举个使用 100Kbps 到 300Kbps 的网络带宽上传视频的例子。
• 音频需要 64Kbps 的吞吐量。
• 标准分辨率的视频需要 500Kbps 的吞吐量。
• 手机的自适应码率用于协调视频跟音频之间的吞吐量差值。视频的码率根据实际可用的网络带宽进行调整。
• 手机根据已通过 RTMP 上传的字节数和上一个间隔的平均权重来决定上传的码率。

未来的方向

• 使用推送机制代替轮询机制，在发送分片请求前，使用 HTTP/2 把分片推送到 PoP 上。

相关文章

• HackerNews
• Facebook Live 的横向扩展
• 为什么 Facebook 和 Mark Zuckerberg 对视频直播火力全开
• 连接世界：Facebook 内部网络基础设施一览
• Gamoloco 掌握着 1476093 个视频直播频道的统计信息

查看英文原文： How Facebook Live Streams To 800,000 Simultaneous Viewers

感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。