Facebook 直播是如何承受海量压力的?

挑战

Facebook 在 2016 年底时的月活用户数有 1860 万,Facebook live 的压力很大,有大量的人开直播,有大量的用户观看直播

整体来看,直播的挑战在于:

  1. 需要能够同时支持数百万的直播流
  2. 对于同一个直播流,需要能够支持数百万的用户

而且直播有一个非常明显的特点,就是非常集中的流量峰值,例如某个名人开了直播,很快就会有大量的用户进来,产生巨大的流量峰值

架构

当很多请求一起进来时,会引发惊群效应,导致严重的流问题,例如延迟、丢包、新用户无法连接 ……

对于这种情况,首先要做的就是阻止请求直接进入流服务器,可以使用多层结构,对请求进行过滤,确保只让必要的请求进入流服务器

其中,Edge Cache 是散布在全球的,Edge Cache 与 Origin Server 是 多对一 的关系,多个 Edge Cache 可以发送请求到同一个 Origin Server

工作过程:

  1. 用户的请求首先到达离自己最近的 Edge Cache server,这个服务器本质上就是一个cache层,不做复杂的处理工作
  2. 如果用户请求的数据包就在 Edge Cache 中,那么直接返回给用户
  3. 如果不在 Edge Cache 中,那么请求会被转到 Origin Server,它也是一个类似 Edge Cache 的缓存服务器
  4. 如果请求的数据包在 Origin Server 中,就返回给 Edge Cache,Edge Cache 再返回给用户,Edge Cache 同时会自己缓存一份
  5. 如果 Origin Server 中没有,请求就会被转到 Streaming Server,然后数据返回给 Origin Server,再经由 Edge Cache 返回给用户,同时,Origin Server 和 Edge Cache 都会进行缓存
  6. 以后有相同的请求时,Edge Cache 和 Origin Server 就可以轻松处理

这个架构极大的减少了 Streaming Server 处理的请求数量,例如有5个请求顺序达到 Edge Cache,只有第一个请求走遍了全程,从 Streaming Server 拿数据,其他4个请求都可以直接从 Edge Cache 中拿到数据

如何防止请求渗漏?

这个架构虽然非常有效,但还有一定的问题,据统计,有 1.8% 的请求会渗漏到 Streaming Server,对于 Facebook 的规模而言,1.8% 也是一个非常大的数字,会给 Streaming Server 造成极大压力

渗漏原因

问题来自并发,当有多个请求一起到达某个 Edge Cache,都要请求数据包A,如果没有命中,那么这几个请求就都会转到 Origin Server

同样的,如果多个 Edge Cache 一起请求同一个 Origin Server,请求也会被转到 Streaming Server

所以,Facebook 的高并发特点就会导致有大量的请求渗漏下去

解决办法

Facebook 的处理办法非常简单,当有多个请求同时到达 Edge Cache,如果他们请求的是相同的数据包,那么就把他们归为一组,放到一个请求队列中,并且只让一个进入到 Origin Server(称为请求合并),当响应回来后,先缓存,然后返回给队列中的各个请求

这个策略同样也在 Origin Server 层进行应用,如果多个 Edge Cache 并发请求相同数据,也会进行合并,只有一个会进入 Streaming Server

这样就很好的解决了并发产生的问题

在 Nginx 中,请求合并可以这样设置:

proxy_cache_lock = on

负载均衡

还有一点很重要,对 Edge Cache servers 进行负载均衡

在流量高峰期,Edge Cache server 的压力会很大,需要使用负载均衡器对请求进行调配,例如离你最近的那个 Edge Cache 已经在处理20万请求,那么负载均衡器就会把你分配到离你稍远一点,但处理压力较小的按个 Edge Cache

负载均衡器会根据距离与压力进行综合权衡,把用户分配到最合适的 Edge Cache server

小结

本文翻译整理自:

https://designingforscale.com/how-facebook-live-scales

其中的核心思路非常值得借鉴:通过多层结构来过滤请求,从而提高服务器的性能和可用性

原文发布于微信公众号 - 性能与架构(yogoup)

原文发表时间:2017-05-07

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏大数据和云计算技术

HBase 的MOB压缩分区策略介绍

HBase应用场景非常广泛;社区前面有一系列文章。大家可以到社区看看看;张少华同学本篇主要讲HBase的MOB压缩分区策略介绍,非常赞!大力推荐!

1461
来自专栏BeJavaGod

SSO - 我们为何需要单点登录系统

SSO,Single Sign On,也就是单点登录,保证一个账户在多个系统上实现单一用户的登录 现在随着网站的壮大,很多服务会进行拆分,会做SOA服务,会使用...

3155
来自专栏腾讯移动品质中心TMQ的专栏

专治时间长 —5分钟测试Android覆盖安装

一、痛点 ? 覆盖安装测试,作为一项基本的测试类型是不可或缺的。它存在的主要价值: 验证老版本覆盖升级到新版本,用户和系统数据能够正确迁移,以及保障用户升级后的...

35810
来自专栏架构师之路

“配置”也有架构演进?看完深有痛感

一、缘起 随着互联网业务的越来越复杂,用户量与流量越来越大,“服务化分层”是架构演进的必由之路。 ? 如上图:站点应用会调用服务,上游服务调用底层服务,依赖关系...

4035
来自专栏JAVA高级架构

如何实现大型网站架构设计的负载均衡

负载均衡 (Load Balancing) 负载均衡建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处...

48610
来自专栏阮一峰的网络日志

Git 工作流程

Git 作为一个源码管理系统,不可避免涉及到多人协作。 协作必须有一个规范的工作流程,让大家有效地合作,使得项目井井有条地发展下去。"工作流程"在英语里,叫做"...

37312
来自专栏安恒信息

软件防火墙和WEB防火墙大比较

 CC攻击是一种成本极低的DDOS攻击方式,只要有上百个IP,每个IP弄几个进程,那么可以有几百上千个并发请求,很容易让服务器资源耗尽,从而造成网站宕机;防御C...

6206
来自专栏CSDN技术头条

【问底】夏俊:深入网站服务端技术(一)——网站并发的问题

本文来自拥有十年IT从业经验、擅长网站架构设计、Web前端技术以及Java企业级开发的夏俊,此文也是《关于大型网站技术演进的思考》系列文章的最新出炉内容,首发于...

2058
来自专栏月牙寂

Golang分布式设计模式之-----星型拓扑分形设计

第一时间获取文章,可以关注本人公众号 月牙寂道长 yueyajidaozhang

3085
来自专栏蛋未明的专栏

【myweb2.0】框架的新思想

1534

扫码关注云+社区

领取腾讯云代金券