[译] Facebook Live如何支持80w用户同时在线

本文主要是介绍[译] Facebook Live如何支持80w用户同时在线，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

写在前面：

这又是一篇翻译了很久的文章--花费时长其实并不久，主要是断断续续翻译前后算起来时长很久。这篇大概是目前翻译得最有共鸣的一篇文章-- 我大沙发厂也有live产品了呢。虽然量级不可比，文中提到的80w在线的流量盛况目前来说也是个遥远的KPI,不过确实在产品迭代中也像文中一样踩了很多坑。作为产品在和讲师沟通配置的过程中，对文末最后提的上传速度那一块的效果体验尤其感同身受。以及，依托于第三方服务来构建自己的产品终归需要不断试错和磨合--和恋爱一样。

最近还有一个关于live而产生共鸣的地方，想来也可以推荐一下，美剧《硅谷》。是的就是文中提到的那个魔笛手Pied Piper。具体点就是第二季大概最后几集里，在公司大概要宣布破产的时候，互怼基友Gilfoyle和Dinesh还有Jared为了撑住因拆解秃鹰孵化的摄像头而失足坠落的工作人员的求救直播引来的凶猛流量导致已达极限的服务器而不停敲代码甚至不顾它已经烧起来的盛况（这句话好长啊，不知道说没说清楚）。虽然情节为了剧情效果颇多不现实，但在我看来确实代表了一些geek精神还有创业维艰的事实。

原文地址 How Facebook Live Streams To 800,000 Simultaneous Viewers

译文部分：

懂得创建世界级服务产品的公司就像掌握核武器的国家一样非常少，Facebook就是其中之一。而Facebook Live, 一款Facebook 新出的直播视频推流产品，就是这些世界级服务之一。

Facebook CEO 马克扎克伯格：

我们做的这项重大的决定就是为了将我们做的大量视频方向的尝试更多地转移到直播方向，因为直播是近来兴起的一种新模式；而不是已经在过去五年甚至十年都存在于网络中的视频…我们已经进入了视频行业的黄金时代。如果你展望五年后的facebook,发现人们都通过直播来分享每日见闻，我一点也不奇怪。

如果你身处广告业务，想来最令人愉悦的就是永远不会停止的广告来源，并且不断扩张大量生成了吧。这就是Google 盈利的主要方式：在呈几何级增长的网页中插入广告。

Facebook Live 能展现如上述的能力体现之一就是一个45分钟的视频：两个人用橡皮筋切西瓜。达到了超过80万人同时在线的顶峰，有超过30万的评论。这就是一个拥有十亿五千万用户的社交网络能创造的病毒式传播效应。

作为对比，2015年超级碗一共有1.14亿的观众，有大概两百多万的用户观看直播。在2015年的电子娱乐展的 Twith 直播中，达到了84万的观看量。9月16号的共和党辩论达到了最高92.1万的同时在线观看人数。

所以对比来看，Facebook做直播最适合不过。需要注意的是，Facebook也可能会出现同一时段有大量直播正在进行的情况。

连线杂志有一篇文章引用了Facebook的首席产品负责人Chris Cox 的话：

有超过100人的直播产品团队（一开始只有12人左右，现在有超过150位工程师参与该项目）
需要支持百万以上的同步直播流而不崩溃
需要支持超过百万的在线观看人数，同时也要考虑全世界上不同的设备适配以及服务商要求

Cox 说“最后发现这是个考验基础架构的难题”。

如果我们能说一说怎么解决这个架构问题的细节，听起来不是很有趣吗？ (为了解决这个问题)我们真的很痛苦!但等等，我们可以聊一下~

来自Facebook 流量团队（traffic team）的Federico Larumbe ，主要优化 Facebook 的CDN 处理能力以及全球加载平衡系统，发表了一次精彩的演讲：Facebook Live 的演变和优化。演讲中他分享了一些关于直播如何实现的细节。

以下是演讲内容的介绍。非常令人印象深刻。

最开始

Facebook 是一个允许用户实时分享内容的新功能（注意这里应该是指Facebook Live）
2015年4月以 Mentions 的移动客户端形式发布，当时只能名人使用，作为和粉丝交流互动的媒介
由此开始了一年的产品优化以及协议迭代
- 他们最开始使用HLS(HTTP Live Streaming) ，这个协议在iPhone设备下被支持，同时也允许他们使用存在的CDN 架构
- 同时也开始研究 RTMP（实时消息传输协议），一个基于TCP 的协议。会有一个视频流和音频流从手机上传到直播推流服务器
  - 优点： RTMP 在推流端和播放端之间有更低的点到点等待时间。这在主播和观众经常互动的场景下非常有用。降低等待时间以及较少的延迟在体验上都是非常棒的改进
  - 缺点：会请求整个架构资源因为它不是基于HTTP 协议。于是需要开发一个全新的 RTMP 代理。
- 也在研究 MPEG-DASH (基于 HTTP 的动态适应串流）
  - 优点：对比HLS 节省了15%的空间
  - 缺点：允许自适应比率串流，编码质量会根据网络上传速度不断变化
- 魔笛手数据压缩方法（开玩笑233333）

2015年12月在超过12个国家发布

视频直播有些不一样—也造成了一堆问题

之前提到的橡皮筋切西瓜的直播的网络传输问题：
- 一个陡增，几分钟内就达到了每秒超过100次请求而且持续增加直到直播结束
- 传输又像碰到障碍一样一下完全停下来
- 换言之，整个数据访问非常迅速而又猛烈
视频直播和正常的录制视频不一样：访问会造成大量的网络请求
- 视频直播更强调参与性因此可能有三倍于录制视频的访问量
- 视频直播会出现在新闻动态推送的顶部因此有更大的可能性被访问
- 通知会被推送到所有页面上的粉丝，因此会有另外一群用户会观看直播
迅速而又猛烈的网络访问请求会造成缓存和加载平衡系统方面的问题
缓存问题
- 很多用户可能想同时观看直播视频，这就是经典的惊群现象
- 高访问请求会给缓存系统造成压力
- 视频都是被分段放进一个二级文件中，高且频繁的访问会让缓存这些视频片段的服务器过载
全球加载平衡问题
Facebook 有遍布全球的网络连接点（PoPs),所以直播的网络传输问题也是分布在全球的
问题就在于防止高访问量对网络连接点的访问过载问题

直播架构构建

以下就是一条直播推流如何由发起人（推流端）传到百万观众面前的过程：

发起人在手机上开启视频直播
手机发送一条RTMP 流到直播流服务器
直播流服务器解码传过来的视频并转码成多个比特率
每个比特率的信息都会创建一个二级 MPEG-DASH 片段
这些片段都被存在一个数据中心缓存器中
在数据中心缓存器里，每个片段又会被送到网络连接点中的缓存器里（一个 PoP 缓存）
在播放端，观众就收到了一个完整的直播视频
观众设备上的播放器会从 PoP 缓存中以每秒一次的速度抓取视频片段

一条直播推流又是如何传播扩散的？

在数据中心缓存器和众多 PoP 缓存器之间有一个聚合结点（multiplication point）, 用户会向 PoP 缓存器发送请求而不是数据中心，而同时有大量的 PoP 缓存器遍布全球。
另一个聚合传播结点在每一个PoP 内部
每一个PoP 内部有两层：一层 HTTP 协议代理层，一层缓存层
播放端在HTTP 代理层请求视频片段，代理会检查改视频片段是否在缓存中，若有则直接从缓存中给出片段，没有则再向数据中心发送片段请求
不同片段被存在不同的缓存器中，这样可以减少不同缓存宿主之间的负载平衡

避免数据中心出现惊群现象

当所有用户同时请求了同一个视频片段会发生什么？
如果该请求的视频片段不在缓存中，则会为每一个用户向数据中心再发送一条请求
请求合并。请求的数量会通过向PoP 缓存添加请求合并而减少。只有第一条请求会被发送给数据中心，其它请求则会被挂起直到第一个响应到达，数据就会被送到所有用户播放端
新的缓存层会被加到代理中以避免热服务器问题
所有的用户请求会被发送到一个缓存主机中等待视频片段，这样可能导致负载过重
代理会增加一个缓存层，只有第一条请求会被代理发送到缓存器，所有接下来的请求则会直接被代理处理

PoPs 仍处于危险之中 —随时需要处理全球性负载均衡问题

所以数据中心已被避免发生惊群问题，但是PoP 节点仍在危险之中。直播的问题在于流量陡增太迅速PoP节点会在达到负载均衡前就已过载。
每一个PoP节点都有一个限制服务器数量和连接点数量。如何避免直播时的迅猛访问对PoP造成过载？
一个叫 Cartographer的系统会把子网与PoP映射起来。这个系统用来处理每个子网和每个PoP节点之间的延迟。这是一种延迟处理方式
每一个PoP的加载都会被处理，每一个用户的请求都会被发送到有足够容量的PoP节点中。在每一个代理中都有计数器来统计他们收到的加载数量。这些计数器的统计会让我们了解到每一个PoP的负载情况
所以又有了关于负载容量限制的考虑和最小化延迟的优化问题
在控制系统内部接收和处理也同样存在延迟
他们将窗口的加载处理时间从一分半缩减到3秒钟—仍存在3秒钟延迟
解决问题的关键是预处理（上述提到的所有的需要处理的）加载时间
通过注入容量预估器来推断内部加载时间以及每一个PoP传输加载时间还有返回后的加载时间
- 如果当前的的加载时长在上升，预测器是如何能判断加载时间会减少？
- 三次样条插值函数（Cubir splines)用来描述插入函数
- 一阶导数和二阶导数会先被执行，如果显示速度为正值则说明加载会增加。如果加速度为负值则意味着速度在减少并最终减为零并开始减速。
- 三次样条插值函数比线性函数更能预测复杂的网络流量类型
- 避免抖动，这类插入函数同时也避免了传输抖动问题
- 接收和处理的延迟意味着在对旧数据的处理，插入函数能减少出错，更精准预测和减少抖动，这样能使负载更接近容量目标
- 当前预测时间是基于最近三次处理的间隔时间（每次间隔有30秒），几乎是瞬时加载