10 月,开发者不可错过的开源大数据大会-2021 WeDataSphere 社区大会深圳站 了解详情
写点什么

Jeff Dean 谈如何在大型在线服务中做到快速响应

2014 年 7 月 13 日

6 月于硅谷举行的 Velocity 2014 大会上,Google 首席科学家 Jeff Dean 做了一场题为《Achieving Rapid Response Times In Large Online Services》的主题演讲,分享了让大型系统运行更加流程以便改善用户体验的种种方法。

Jeff 首先以 Google 的搜索服务为例,说明了何为大扇出服务(Large Fanout Service),即一个搜索请求需要有大量子系统(Web、新闻、图像、视频、博客等等)参与其中,以便提供更丰富的搜索结果。在 Google,基本不会为特定的服务提供特定的机器,而是将服务都部署在一个机器池中,这被称为共享环境(Shared Environment),Google 的共享环境大致会包含以下几个部分——Linux、调度系统、文件系统 ChunkServer、多种其他系统服务、Bigtable Tablet Server、随机 MapReduce 任务、CPU 密集型任务以及随机应用。它的好处是可以极大地提升利用率,但同时也会带来诸多无法预测的问题,比如网络拥塞等等。尤其是响应时间的长尾现象比较明显,一次请求的平均响应时间是 10 毫秒,但是却有 99%ile 的响应时间大于 1 秒,在大扇出服务中,如果需要调用 100 台服务器获得最终结果,那有 63% 的请求耗时会大于 1 秒。

针对延时问题,有些基本的降低延时的技术:

  • 定义不同的服务级别,针对服务器上的请求队列和网络流量设定优先级。
  • 减少线头阻塞(head-of-line blocking),将大的请求打散成一系列小请求;比如,一个读请求需要读取 64MB 数据,而另有一个 100KB 的读请求必须等前者完成了才能得到处理,此时可以将大请求分为多个小请求,以便 100KB 的那个请求能及时得到处理。
  • 管理好昂贵的后台活动,比如分布式存储系统中的日志压缩就算昂贵的后台活动,此类活动可以考虑在负载低峰期去执行。

Jeff 指出,我们要做的事就是基于一堆不可靠的资源打造一个可靠的整体,基于一堆无法预估的资源打造可以预测的整体。在延时处理方面,Jeff 将对应的技术分为两大块:

  • 跨请求适应(cross request adaptation),通过检测最近的行为,采取一些措施来优化后续的请求处理,通常会和负载均衡有关,生效时间大约是十几秒到几分钟。
  • 同请求适应(within request adaptation),在当次请求中,对响应较慢的子系统采取一些措施,以改善本次请求的整体响应时间,通常是立刻生效的。

随后,他分别就两类技术进行具体展开说明。

1. 跨请求适应

可以通过细粒度的动态分区,将大数据集或大型计算拆分到多台服务器上,一般一台服务器上会分到 10 到 100 个块,BigTable 和 GFS 就是这么处理的。

这么做的好处是显而易见的,比如,当一台机器负载过重时,可以将其中的一部分内容移动到另一台上;可以加速故障恢复,多台服务器分别恢复不同的数据块;实现选择性复制,针对重度使用的内容可以动态或静态地生成更多副本。

当服务器的响应变慢时,有可能这和当时发送的数据有关,但更多情况下是受到干扰的影响,比如共享服务器上其他任务造成的 CPU 或网络尖刺。此时可以选择将部分负载移动到其他服务器上以便改善延时情况,也可以在其他服务器上创建更多该分区的副本,继续给这台服务器发送请求(正常请求发给其他服务器了,发给本服务器的请求只是一份镜像)持续观察延时情况,待延时正常后再让其提供正常服务。

2. 同请求适应

同请求适应的目标是在不会增加太多资源消耗的情况下减少整体延时,同时还要保障系统安全运行。

有时一些失败是和请求数据有关的,比如一些测试过程中没有发现的“奇怪数据”会造成系统宕机等等,如果一次性将有问题的请求发给所有节点,那么所有节点就都出问题了。在 Google 会使用一种名为 Canary Requests 的请求,即把请求先发给一个节点,收到响应后,基本可以证明这个查询是可行的,随后再将其发给其他节点。

Jeff 在随后的时间里详细介绍了他们使用的另一项技术——备份请求(Backup Requests),大致的思路是先把请求发给一个副本,请求会被放进队列;随后再给另一个副本发送相同请求,如果第二个副本处理地很快,处理完毕后发回结果,客户端再给第一个副本发送取消任务请求。

以 In-memory BigTable Lookups 为例,数据存储了两份,将在 100 个 Tablet 中发送 1000 个键查询,统计最后一个键返回的总耗时。在没有备份请求时,平均耗时 33 毫秒,99%ile 为 52 毫秒,99.9%ile 高达 994 毫秒;当在 10 毫秒后发送备份请求时,平均耗时降为 14 毫秒,99%ile 和 99.9%ile 分别降到了 23 毫秒和 50 毫秒,此外还测试了在 50 毫秒后发送备份请求的情况,耗时同样比没有备份要好,但较前者表现略逊一筹。本案例中,延时 10 毫秒的备份请求仅增加了不到 5% 的额外请求负担,在延时 50 毫秒的情况下,更是下降到不足 1%。可见备份请求能在很大程度上改善延时的长尾效应,同时并未增加太多开销。

备份请求技术还可进一步优化,在发送请求时将处理请求的另一台服务器信息也纳入请求中,一旦一台服务器开始执行,就直接通知另一台取消执行,这项优化称为跨服务器取消。Jeff 同样提供了一个例子,在分布式文件系统客户端中发送读请求,等待 2 毫秒后发送备份请求,耗时情况如下:

  • 集群处于空闲状态
    • 没有备份请求,50%ile 为 19 毫秒,90%ile 为 38 毫秒,99%ile 为 67 毫秒,99.9%ile 为 98 毫秒
    • 有备份请求,50%ile 为 16 毫秒,90%ile 为 28 毫秒,99%ile 为 38 毫秒,99.9%ile 为 51 毫秒
  • 集群正在进行大量排序
    • 没有备份请求,50%ile 为 24 毫秒,90%ile 为 56 毫秒,99%ile 为 108 毫秒,99.9%ile 为 159 毫秒
    • 有备份请求,50%ile 为 19 毫秒,90%ile 为 35 毫秒,99%ile 为 67 毫秒,99.9%ile 为 108 毫秒

两种情况下,使用备份请求延时都有显著改善,99%ile 分别下降了 43% 和 38%,在第二种情况下备份请求只引入了大约 1% 的额外磁盘读请求。如果没有备份请求,集群需要一直处于低负载状态,而使用了备份请求,集群则可处于相对较高的负载,同时还能有相对较好的响应延时。

对于备份请求而言,最坏的情况即是两台机器几乎同时收到请求,并且都处理了请求,这会带来一定的资源浪费。当然,也可以引入第三个请求,但通常情况下向两台服务器发送请求就已经足够了。在演讲后的 Office Hour 中,Jeff 表示备份请求也不是万能的,对于一些不可重复执行得请求,比如在线交易,就不能使用备份请求,以免造成数据不一致等情况。

在本次 Velocity 大会上,Jeff Dean 的演讲时间较短,如果您对他的具体演讲内容感兴趣,可以观看官方视频。同时,也推荐您去阅读 2013 年 Jeff Dean在斯坦福的演讲还有一篇更早的材料。我们希望有一天能够邀请到 Jeff 到国内现场为广大 InfoQ 的读者做一次分享,到时您会来参加么?

2014 年 7 月 13 日 08:485152
用户头像

发布了 135 篇内容, 共 52.9 次阅读, 收获喜欢 35 次。

关注

评论

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

darknet A版安装

Dreamer

Dubbo-go Server端开启服务过程

apache/dubbo-go

dubbo dubbo-go dubbogo

手动造轮子——基于.NetCore的RPC框架DotNetCoreRpc

yi念之间

RPC ASP.NET Core

线上Java程序占用 CPU 过高,请说一下排查方法?

古时的风筝

Java JVM cpu 100%

书写高质量SQL的30条建议

诸葛小猿

MySQL SQL优化

high-performance-tidb-challenge 记录

程序员老王

DDIA 读书笔记(5)数据分区方案

莫黎

读书笔记

天源迪科受邀出席“第四届央企电商化采购发展高峰论坛"

DT极客

训练营第三周作业

大脸猫

极客大学架构师训练营

甲方日常 45

句子

工作 随笔杂谈 日常

Week 5学习总结

balsamspear

极客大学架构师训练营

【Knative系列】一文读懂 Knative Serving扩缩容的原理

公众号:云原生Serverless

Serverless knative autoscaler kantive

响应式编程简介之:Reactor

程序那些事

响应式编程 reactor Reactive 程序那些事 响应式系统

交易所开发技术,数字货币交易系统源码搭建

135深圳3055源中瑞8032

英特尔首批独显笔记本亮相,非凡S3x纵享轻薄新体验

新闻科技资讯

搭载设计师级独显英特尔Xe MAX,非凡S3x体验全能创作

新闻科技资讯

性能测试,简单的压测工具

garlic

极客大学架构师训练营

Flink 1.11 与 Hive 批流一体数仓实践

Apache Flink

flink 流计算 实时计算

蚂蚁金融推迟上市:互联网金融是否要遭遇滑铁卢

石头IT视角

USDT支付系统开发方案,区块链币支付系统搭建

135深圳3055源中瑞8032

【性能优化】纳尼?内存又溢出了?!是时候总结一波了!!

冰河

性能优化 内存泄露 高并发 高性能 内存溢出

Android 扫码 生成二维码

Java android kotlin zxing camera

广东云算力矿机系统开发,挖矿平台搭建

135深圳3055源中瑞8032

手动造轮子——为Ocelot集成Nacos注册中心

yi念之间

nacos ASP.NET Core Ocelot

全球首批搭载英特尔Xe MAX独显惊艳上市,非凡S3x尽显创作魅力

新闻科技资讯

英特尔进军独显领域,第一批搭载锐炬®Xe MAX独显轻薄本已问世!

新闻科技资讯

区块链数字货币钱包开发模式,深圳数字钱包开发

135深圳3055源中瑞8032

在深夜加油站遇见哈利波特

脑极体

Week 7 命题作业

阿泰

Week 5命题作业

balsamspear

极客大学架构师训练营

架构师第一期作业(第 7 周)

Cheer

课程作业

开源中间件技术学习路线

开源中间件技术学习路线

Jeff Dean谈如何在大型在线服务中做到快速响应-InfoQ