揭秘百万人围观的Facebook视频直播

现任Facebook组技术PM，负责Facebook的视频和直播基础设施。曾任微软的首席项目经理和和开发经理，负责Azure Active活动目录的开发。

几个月前，我们开始推出 Facebook Mentions 的 Live 功能，该功能让认证后的公众人物可以通过 Mentions 对其 Facebook上 的粉丝进行视频直播。我们在这次部署中学到了很多，并且我们已经开始测试 Facebook 用户使用的视频直播分享功能，第一步我们先从美国使用 iPhone 的这一小部分用户开始测试。

为 Facebook 构建视频直播是一项具有挑战性的大规模工程活动。在 Facebook Mentions 的 Live 功能上，我们必须解决巨大的流量峰值问题。Facebook 上的公众人物粉丝可能多达百万，这些粉丝全都想要在同一时间观看视频；我们还有一个目标，就是创造均衡负载的新办法。为了开始向更多的人推出视频直播，我们通过允许 RTMP 进行回放，从而把直播的延迟压缩到几秒钟。我们希望这些低延迟的直播会改善用户体验，让直播者和观看者之间更高的互动性。在这篇文章中，我们将粗略地看一下我们在每次发布时解决的问题，我还将向你解释我们为负载均衡和 RTMP 实现问题所选择的解决方案。

解决“惊群效应”问题

Facebook 上有一些公众人物的粉丝多达百万。这就意味着当公众人物开始视频直播时，我们需要能够处理超过一百万人同时观看直播的潜在情况，比如范·迪塞尔的现场直播就是如此。大规模系统都不喜欢流量高峰，特别是当很多请求在一瞬间一起发生时。每到这种时候，我们就说我们遇到了一个“惊群效应”问题——太多的请求可能会使系统过载，导致直播的延迟、信息丢失，以及连接断开。

可以说，防止过载的最好方法就是不让负载穿过大门。与其让客户端直接和直播流服务器连接，我们让边缘缓存（edge caches）的网络分布到全局。

在我们的实现中，一个视频直播被分割成了 3 秒的 HLS 段。显示直播的视频播放器会继续请求这些段。边缘数据中心的一个 HTTP 代理会处理段请求，该数据中心会检查这个段是否已经存在于一个边缘缓存中。如果在缓存中，它就会被返回。如果不在，代理就会向源缓存发出 HTTP 请求，而源缓存是另一个具有相同架构的缓存层。

如果段不在源缓存中，就需要向处理这个特定视频流的服务器请求。

然后服务器用段来返回 HTTP 响应，这个段就被缓存在每一层中，所以接下来客户端就会更快地收到这个段。利用这种组合，超过 98% 的段都已经存在了离用户较近的边缘缓存中，而源服务器只会收到很少部分的请求。

为了防止这种情况发生，边缘缓存为第一个请求返回缓存未命中，然后把接下来的请求放进队列中。一旦 HTTP 响应从服务器回来，这个段就被存储在了边缘缓存中，而列队中的请求也会作为缓存访问而获得边缘的响应。

为了防止这种情况发生，边缘缓存为第一个请求返回缓存未命中，然后把接下来的请求放进队列中。一旦 HTTP 响应从服务器回来，这个段就被存储在了边缘缓存中，而列队中的请求也会作为缓存访问而获得边缘的响应。

这种方法有效地解决了惊群效应，降低了输送给源服务器的负载。源服务器反过来也用相同的机制来处理来自多个边缘缓存的请求——相同的对象既可以从芝加哥的边缘缓存中请求，也可以从迈阿密的边缘缓存中请求。

在 RTMP 中，直播被分成了两个流：一个视频流和一个音频流。这些流被分解成了 4KB 的区块，这些块可以在 TCP 连接中被多路复用，即视频和音频块被交叉存取。当视频比特率达到 500Kbps 时，和每个 HLS 段的 3 秒时长相比，每个块只有 64ms，它让穿过所有组件的流都更加顺畅。只要编码了 64ms 的视频数据，直播者就可以发送数据；转码服务器可以处理这个区块并且生成多种输出比特率。区块随后通过代理被转递出去，直到到达播放器。