【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

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

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

关注

评论

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

ironSource 出品 AdQuality 解决方案全新升级,助力开发者管理应用内广告

教你实现一个朴实的Canvas时钟效果

华为云开发者联盟

标签 函数 canvas 时钟

视频剪辑软件对比之:会声会影与剪映

懒得勤快

原地起飞!字节工程师开源了GitHub的Java开发百宝手册后,被骂哭

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

IOS技术分享| any自习室场景实现

anyRTC开发者

音视频 在线教育 移动开发 ios技术分享

移动端短语音消息音频格式选择

轻口味

android 音视频 9月日更

火爆全网的Spring Security手册及源码笔记,在Github上标星103K

编程 架构 面试 程序人生 金九银十

阿里云内部 WebRTC 研究分享| 内容合集

阿里云视频云

阿里云 音视频 WebRTC 视频云 技术专题合集

Java中级开发笔试题及答案,成功入职腾讯月薪45K,

Java 程序员 后端

Java中高级面试必知必会,高级Java开发面试解答之线程篇,

Java 程序员 后端

李沐亚马逊资深首席科学家 - 动手学深度学习 易筋 ARTS 打卡 Week 64

John(易筋)

ARTS 打卡计划

2021 CHIMA观感:医疗信息化发展的几个趋势,值得关注

菜根老谭

医疗信息化

Redis缓存那点破事 | 绝杀面试官 25 问!

Java redis 架构 后端 计算机

webrtc Fec kPacketMaskRandomTbl 概述

webrtc developer

webrtc、 fec mask

字节大佬的「算法界Offer收割机」火爆Github,短时间获上万star

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

【万字干货】OpenMetric与时序数据库存储模型分析

华为云开发者联盟

OLAP 时序数据库 index Metric Timeseries

腾讯出品526页异步非阻塞通信领域巅峰之作:Netty IO核心技术指南

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

Java中级笔试题百度文库,基础+进阶+高级,

Java 程序员 后端

Java中高级岗面试为何越来越难,学习Java开发的步骤,

Java 程序员 后端

Java中高级岗面试为何越来越难,都2021年了,还不会Redis?

Java 程序员 后端

FunTester测试框架Redis性能测试实践

FunTester

redis 性能测试 测试框架 FunTester

少女银四失足,偶得“阿里Java神级题库(25专题)”,金九稳了

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

常见的IT自动化运维工具有哪些?推荐一款好用的?

行云管家

阿里云 运维 IT运维 PSSH

过二级等保需要哪些安全设备?多少钱?

行云管家

数据库 网络安全 等保 等级保护

在 CentOS 7上安装Sonatype Nexus Repository OSS

DisonTangor

nexus Ops

FunTester抄代码之路

FunTester

Jmeter 测试框架 HttpClient FunTester ngrinder

计算机操作系统学习笔记 | 进程

Regan Yue

操作系统 进程 9月日更

Java中级开发面试题,只需一篇文章吃透Java多线程技术,

Java 程序员 后端

java中间件、数据库与spring框架,Java性能优化最佳实践,

Java 程序员 后端

MySQL连接控制插件介绍

Simon

MySQL

网易24周年,竟拿出内部进阶必备的网络协议笔记,给程序员发福利

公众号_愿天堂没有BUG

Java 编程 程序员 架构 面试

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