写点什么

Facebook 视频直播如何面对 80w+ 并发观众

  • 2016-07-03
  • 本文字数:3822 字

    阅读完需:约 13 分钟

了解如何构建全球规模分布式服务的公司,其数量甚至比拥有核武器的国家数量还要少。Facebook 就是这样的一家公司,该公司最新发布的视频直播服务 Facebook Live 正是这样一种全球规模的服务之一。

Facebook 的 CEO Mark Zuckerberg 认为:

我们做了一个重大决定,打算将视频方面的工作重心转向在线直播视频领域,因为相比过去五到十年来大家将视频上传网上,视频直播是一种新兴的形式…我们开始步入视频领域全新的黄金时代。过去五年来,人们每天在 Facebook 观看和分享的内容大部分都是视频,这一点丝毫不会让人感到惊讶。

如果从事广告行业,还有什么能比通过永无止境,随时扩展,自由创建的方式为观众提供广告内容更能让人激动的?Google 为以指数形式扩张的互联网提供广告业务也正是利用了这样的经济意义。

Facebook 视频直播服务有一个绝佳的范例,在一段 45 分钟的视频里,两个人用橡皮筋勒爆了一只西瓜。峰值时期这个视频吸引了超过800,000 人同时观看,并获得超过300,000 条评论。面对超过15 亿人组成的社交网络,很容易实现这种规模的病毒式传播。

相比而言,2015 年超级碗的观众总数 1.14 亿人,在线直播观众数均值为 236 万。2015 年 E3 展会期间 Twitch 的观众数峰值为 840,000 人。9 月 16 日美国共和党辩论的在线直播并发观众数峰值为 921,000 人。

Facebook 的技术水平确实高高在上。另外需要注意,大家观看那段西瓜视频的同时,还有很多用户在通过 Facebook 观看大量其他在线视频。

Wired 一篇文章引用了 Facebook 首席产品官 Chris Cox 的话,据他称,Facebook:

  • 有超过一百位员工正在从事与视频直播有关的工作。(该项目最初大约有 12 人,现在已经有超过 150 名工程师)
  • 必须能在不崩溃的情况下为 _ 数百万个并发直播 *_ 提供支撑。
  • 必须能为同一个直播视频的数百万并发观众提供支撑,同时必须为全球不同供应商的不同设备提供无缝的视频直播。

Cox 认为“最后发现这是对基础结构提出的一个巨大挑战。”

如果能深入了解这个基础结构挑战是如何解决的岂不是很有趣?那就继续读下去吧!

Facebook 网络流量团队主要负责开发用于驱动 Facebook CDN 和全球负载平衡系统的缓存软件,来自该团队的 Federico Larumbe 最近做了一场很棒的演讲: Facebook Live 的缩放,他在其中分享了一些视频直播服务的细节。

我对这些内容的注解如下。这真是让人印象深刻。

故事的起源

  • Facebook Live 是一项新功能,可供用户实时分享视频内容(注意,这只是 Facebook 众多功能之一)。

  • 2015 年 4 月发布的 Live 服务最初只能由社会名流通过 Mentions 应用使用,借此与粉丝展开互动。

  • 随后经历了长达一年的产品完善和协议迭代。

    • 最初使用 HLS (HTTP Live Streaming)协议,iPhone 可支持该协议,并且这个协议可以充分支持现有的 CDN 体系结构。

    • 同时他们还开始研究 RTMP (Real-Time Messaging Protocol)这种基于 TCP 的协议。通过这种协议可以将视频流和音频流从手机发送到 Live Stream 服务器。

      • 优势:RTMP 在广播方和观众之间的端到端延迟更低,在用户需要相互交互的互动广播方面这一点很重要。更低的延迟和不到几秒钟的时延让体验大为不同。
      • 劣势:需要具备一整套全新的体系结构,因为该协议并非基于 HTTP 的。为了实现规模化,还需要开发一套新的 RTMP 代理。
    • 此外他们还考虑过 MPEG-DASH (Dynamic Adaptive Streaming over HTTP)。

      • 优势:相比 HLS 其存储空间利用率可提高 15%。
      • 优势:支持自适应视频码率,可根据网络吞吐量动态调节编码质量。
    • Pied Piper Middle-Out Compression Solution :(纯属玩笑)

  • 该服务于 2015 年 12 月在十多个国家上线。

直播视频有大不同,会产生新问题

  • 上文提到的西瓜视频造成了这样的一种流量模式:

    • 首次增幅非常陡峭,每秒请求数在几分钟内就超过了 100 次,并且在视频播放完毕之前还在持续增加。
    • 随后流量大幅降低。
    • 换句话说,流量呈现出“尖峰”模式。

  • 直播视频与普通视频的不同之处在于:会造成“尖峰”模式的流量

    • 相比普通视频,直播视频更容易产生3 倍以上的访问量。
    • 直播视频通常会出现在用户“消息源”的最顶端,因此被访问的概率更高。
    • 每个公众页面的所有粉丝会收到通知消息,这群人很可能也会观看这些视频。
  • “尖峰”流量会导致缓存系统和负载平衡系统遇到问题。

  • 缓存的问题

    • 可能有很多人希望同时观看直播视频,这就是经典的惊群(Thundering Herd)问题
    • 尖峰流量的模式会给缓存系统造成极大压力。
    • 视频内容会拆分为多个一秒时长的片段,遇到尖峰流量时,提供这些片段的服务器可能会过载。
  • 全球负载平衡的问题

    • Facebook 具备遍布全球的入网点(PoP),Facebook 的流量遍布全球。
    • 防止尖峰流量造成 PoP 过载,这是一个很大的挑战。

体系结构概览

直播视频是这样通过一位广播者播放给数百万观众欣赏的:

  • 广播者通过手机启动视频直播。
  • 手机将一条 RTMP 视频流发送给 Live Stream 服务器。
  • Live Stream 服务器对视频解码,并转码成不同码率。
  • 每个码率的版本可持续生成一秒时长的一系列 MPEG-DASH 片段文件。
  • 片段存储在数据中心缓存内。
  • 缓存的片段从数据中心发送至遍布全球的入网点缓存内(PoP 缓存)。
  • 播放端的观众收到一条 Live Story。
  • 观众设备上的播放器开始以每秒一个的速度从 PoP 缓存获取视频文件片段。

如何进行缩放?

  • 数据中心缓存和多个 PoP 缓存之间存在相乘关系,用户访问的是 PoP 缓存而非数据中心缓存,全球分布着大量 PoP 缓存。

  • 此外每个 PoP 内部也存在这相乘的关系。

    • PoP 内部分为两层:一层 HTTP 代理,以及一层缓存。
    • 观众通过 HTTP 代理请求视频片段,随后代理会检查该片段是否位于缓存中。如果位于缓存中,可直接将片段返回给观众;如果不在缓存中,则会向数据中心发出该片段的请求。
    • 不同的片段存储在不同缓存中,借此通过多个缓存主机实现负载平衡。

保护数据中心防范惊群问题

  • 如果所有人在同一时间请求同一个片段会怎样?

  • 如果片段不在缓存中,每个观众只会向数据中心发送一个请求。

  • 请求合并(Request Coalescing)。通过为 PoP 缓存添加请求合并,可减少请求的数量,只有第一个请求会被发送至数据中心,在收到第一个请求的响应并将数据发送给所有观众前其他请求会被暂挂。

  • 为避免热服务器问题(Hot Server problem)为代理增加了一个新的缓存层。

    • 如果将需要某一片段的所有观众发往同一个缓存主机,该主机可能会过载。
    • 代理增加了一个缓存层。只有发往代理的第一个请求可以实际创建到缓存的请求,其他所有请求可以直接通过代理获得响应。

PoP 依然处于风险中 – 可通过全球负载平衡加以缓解

  • 面对惊群问题,数据中心可以获得妥善保护,但 PoP 依然处于风险中。问题在于视频直播的“尖峰”实在是太大了,PoP 可能会在负载到达负载平衡器前就已过载。

  • 每个 PoP 的服务器和连接数有限,如何预防“尖峰”导致的 PoP 过载?

  • 通过一个名为 Cartographer 的系统将互联网子网映射到 PoP。该系统可以衡量每个子网和每个 PoP 之间的延迟,这就是所谓的延迟衡量。

  • 每个 PoP 的负载都会被衡量,每个用户会被发送至具备足够容量,距离最近的 PoP。代理包含对所接收的负载进行衡量的计数器,这些计数器可进行聚合汇总,这样就可以知道每个 PoP 的负载情况。

  • 在容量的局限和最小化延迟方面还需要进行优化。

  • 控制系统本身的衡量和回应也存在延迟。

  • 将负载的衡量窗口从原本的 1.5 分钟缩短至 3 秒,但依然存在一个 3 秒的窗口。

  • 为此需要在实际发生之前对负载进行预测

  • 通过实施容量估算程序,可以从每个 PoP 之前的负载和当前的负载推断出将来的负载情况。

    • 如果负载正在增加,估算程序如何预测负载何时降低?
    • 此时为插值(Interpolation)函数使用了三次样条函数(Cubic splines)
    • 首先执行一阶和二阶导数。速度为正值意味着负载正在增加,加速度为负意味着速度增速正在下降,最终将归零并开始降低。
    • 三次样条函数可以比线性插值(Linear interpolation)预测出更为复杂的流量模式。
    • 避免摆动。这个插值函数还解决了摆动的问题。
    • 衡量和回应所存在的延迟意味着作为决策依据的数据不够新。插值可以减少错误做出更精确的预测,并能降低摆动。这样负载才能更接近目标容量。
    • 目前预测工作是基于最新的三个区间做出的,每个区间时长 30 秒,几乎可以代表负载的瞬时状况。

测试

  • 首先需要让 PoP 过载。
  • 为了模拟直播流量开发一个负载测试服务,并将其分布至全球 PoP 中。
  • 可以模拟生产负载 10 倍的环境。
  • 可以模拟一位观众一次请求一个视频片段。
  • 该系统帮助 Facebook 发现并解决了容量估算程序中存在的问题,能借此对参数进行微调,并可验证缓存层解决了惊群问题。

上传的可靠性

  • 实时上传视频这个操作本身就充满挑战。
  • 例如,某次上传可能只有 100-300Kbps 的可用带宽。
  • 音频需要 64Kbps 的吞吐率。
  • 标清规格视频需要 500Kbps 的吞吐率。
  • 手机上可以使用自适应编码技术应对视频和音频吞吐率不足的问题。视频编码时的码率可以根据可用网络带宽进行调整。
  • 为了确定上传的码率,手机会衡量 RTMP 连接的上传速度,并与上一个区间的结果取加权平均值。

未来的发展方向

  • 不再使用请求拉取机制,而是研究一种推送机制,利用 HTTP/2 在视频片段被请求之前将其推送至 PoP。

相关文章

作者

Todd Hoff ,点击这里阅读英文原文。


感谢陈兴璐对本文的审校。

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

2016-07-03 17:254734
用户头像

发布了 283 篇内容, 共 107.2 次阅读, 收获喜欢 62 次。

关注

评论

发布
暂无评论
发现更多内容

如何用java校验SQL语句的合法性?(提供五种解决方案)

EquatorCoco

Java 教程 SQL语句

AntDB数据库亮相2023操作系统产业大会,携手合作伙伴共建网信生态

亚信AntDB数据库

数据库 AntDB AntDB数据库 企业号 7 月 PK 榜

Linux系统开启或关闭SELinux。

百度搜索:蓝易云

Linux 运维 Mac 云服务器 SELinux

ES 数据太敏感不让看,怎么办?

极限实验室

ES hash 数据脱敏; 敏感数据 正则脱敏

保险企业如何做好数据安全合规与敏感数据保护

原点安全

数据安全 保险科技 敏感信息 敏感数据保护 个保

极限抵御DDoS攻击!高防主机守护您的网站安全!

一只扑棱蛾子

高防主机

RisingWave 1.0 版本正式发布!

吴英骏

数据库 rust 云原生 数据架构 流处理

初窥低代码 | 社区征文

神木鼎

低代码 年中技术盘点

Netty入门之可写事件以及多线程版的通信

派大星

【会议】《卧龙:苍天陨落》制作人山际真晃与总监平山正和将联袂出席 2023 中国游戏开发者大会(CGDC)

CGDC中国游戏开发者大会

设计 开发 游戏开发 ChinaJoy

1W+规则,20W+字段,某城商行数据分类分级有多卷?

极盾科技

数据安全 数据分类分级

【7.7-7.14】写作社区优秀技术博文一览

InfoQ写作社区官方

热门活动 优质创作周报

当AGI遇上能源寡头,会碰撞出什么样的火花?

TE智库

特斯联

KaiwuDB CTO 魏可伟:多模架构 —“化繁为简”加速器

KaiwuDB

数据库 AIOT KaiwuDB 多模架构

DevOps in China:15年来,DevOps在中国经历了什么?

DevOps和数字孪生

嵌入式DevOps

袋鼠云产品功能更新报告06期|数栈产品功能升级,做产品我们是认真的!

袋鼠云数栈

大数据 产品 数据中台

一文帮你搞定H5、小程序、Taro长列表曝光埋点 | 京东云技术团队

京东科技开发者

小程序 taro 前端 曝光埋点 企业号 7 月 PK 榜

2023最新发布:Java 面试突击大全 带你摸熟 20+ 互联网公司面试考点

架构师之道

编程 程序员 java面试

无代码落地进企业,轻流不断扩大交友圈

ToB行业头条

CentOS7系统服务器密码忘记的解决办法?

百度搜索:蓝易云

云计算 Linux centos7 运维 云服务器

IT安全运维管理系统哪个好?适合中小企业的哪款好?

行云管家

云计算 IT运维 云管理 安全运维

学到就是赚到!NodeJS 实战系列:个人开发者应该如何选购云服务

不在线第一只蜗牛

node.js 实战开发

与 AI 同行,利用 ChatGLM 构建知识图谱

NebulaGraph

人工智能 知识图谱 LLM

继长白山历史文化园三园一区后,鼎益丰再造龙狮谷新项目

Geek_2d6073

Nautilus Chain 更换全新测试网,主网即将在不久上线

大瞿科技

同城双中心 DR Auto-Sync 主中心意外故障恢复

TiDB 社区干货传送门

数据库架构设计 7.x 实践

官宣!菁英实习生计划启动,百度大模型团队诚邀你的加入

飞桨PaddlePaddle

人工智能 百度 paddle 飞桨 百度飞桨

智能合约编写高级篇(一)获取区块时间

BSN研习社

大咖直播专场 | 数据库集群方案简介

KaiwuDB

KaiwuDB 数据库集群方案介绍

IoT 场景下 TDengine 与老牌时序数据库怎么选?看看这份TSBS报告

爱倒腾的程序员

数据库·

AIGC:新AI时代,推动数字人进化的引擎

华为云开发者联盟

人工智能 华为云 华为云开发者联盟 企业号 7 月 PK 榜

Facebook视频直播如何面对80w+并发观众_Meta_Todd Hoff_InfoQ精选文章