写点什么

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:254694
用户头像

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

关注

评论

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

用扩展的方式在 PHP 中使用 Kafka

北桥苏

php Kakfa

绝~ 阿里内部“Java进阶必备宝典”,理论到实战,一键通关

程序知音

Java java架构 Java进阶 后端技术

Django笔记二十七之数据库函数之文本函数

Hunter熊

Python django 文本函数 concat substr

ElasticSearch中文分词和模糊查询

北桥苏

php elasticsearch

如何使用Go语言实现软件设计中的‘对扩展开放、修改关闭’原则

Jack

Charles(HTTP代理服务器)注册安装教程

Rose

Charles注册码 Charles下载 HTTP代理服务器

我通过 tensorflow 预测了博客的粉丝数

北桥苏

人工智能 深度学习 tensorflow

如何获得高并发经验?看这篇文章就够了

Java永远的神

程序员 系统设计 高并发 架构师 java面试

理解 K8s 多集群(上):构建成熟可扩展云平台的核心要素

张旭海

k8s 多云 K8s 多集群管理

OPPO关停自研芯片公司哲库,这对行业将产生什么影响?

福大大架构师每日一题

芯片 福大大

PS 2023中文一键安装版 Photoshop永久使用

Rose

Photoshop 2023中文版 photoshop下载 PS2023下载 PS 2023破解

关于 PHP 启动 MongoDb 找不到指定模块问题

北桥苏

php mongodb

如何在业务代码中使用 ThinkPHP5.1 封装的容器内反射方法

北桥苏

thinkphp 反射调用

华为许超:伙伴成功,才有华为企业业务成功

脑极体

华为

C++中的可移植性和跨平台开发

小万哥

SocketLog 的基本使用

北桥苏

php thinkphp SocketLog

香港影视集团星光文化旗下 NFT 发售平台——StarNFT 上线

BlockChain先知

Python潮流周刊#1:如何系统地自学Python?

Python猫

Python

Prompt learning 教学[技巧篇]:通过增加示例、引导词、特殊符号指令等方式让chatgpt输出更好的答案

汀丶人工智能

人工智能 自然语言处理 ChatGPT prompt learning

阿里架构师总结的互联网面试必问Java八股文进阶手册,堪称面试前必看系列

开心学Java

Java 编程 面试 java面试 八股文

我的网站中了马!

北桥苏

php thinkphp 网站开发

工赋开发者社区 | 何谓智能工厂?国内外智能工厂建设的现状分析

工赋开发者社区

CleanMyMac X专业的Mac清理工具,一次激活,永久使用

Rose

CleanMyMac下载 CleanMyMac v4.13.4 Mac清理优化工具 苹果电脑系统清理软件

在Inteillj IDEA中使用Spark操作Hive

北桥苏

spark hive Big Data

n-Track Studio 9录音、音频编辑一站式完成!

真大的脸盆

Mac 音频制作 Mac 软件 音频处理 录音工具

京东内部疯传的Redis学习笔记,被阿里P7夸爆

小小怪下士

Java redis 程序员

iOS MachineLearning 系列(16)—— 几个常用的图片分类CoreML模型

珲少

理解 K8s 多集群(下):解决方案对比与演进趋势

张旭海

k8s 多云 K8s 多集群管理

C语言编程-环境设置

芯动大师

C语言 环境搭建 三周年连更

超级独角兽 Databricks 的崛起之路

CnosDB

时序数据库 开源社区 CnosDB Databricks

测试写代码的好处

FunTester

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