注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

还东国的博客

行之苟有恒,久久自芬芳

 
 
 

日志

 
 

(转载)Facebook是如何支持80万并发视频流直播的?  

2016-11-25 14:04:57|  分类: |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
Facebook是如何支持80万并发视频流直播的?

http://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw==&mid=2659598533&idx=1&sn=f5d6169b8da6a8a09c7e7697546356ae&chksm=8be995d7bc9e1cc1286d4ff7edabcc2a52bbabb10b0933e1a85a5058b7c409f7e6f0e5d5a720&mpshare=1&scene=23&srcid=11255X0F9DSvKKl9vg4lv3jy#rd

2016-11-24 薛命灯 译 

具备构建横跨全球的分布式服务能力的公司寥寥无几,甚至比拥有核武器的国家还要少。然而,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是一个可以让人们实时分享视频的新项目。它在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%的空间。

·         缺点:它支持自适应比特率,编码质量取决于网络的吞吐量。

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

之前提到的撬西瓜视频的流量模式:

·         刚开始增涨很快,在几分钟内就超过每秒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上。

推荐一个架构类的会议

当业务量爆发增长时,高可用架构是永恒的话题。出行、电商、社交网络、房产,每个看似不同领域的技术架构都承受着相同的高并发冲击。滴滴、京东、Facebook以及链家,四个不同的行业巨头将在这里分享他们自己在对高可用架构的见解。点击“阅读原文”了解详情。

 
  评论这张
 
阅读(18)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017