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

标签: 架构设计 软件技术 Google Jeff Dean | 发表时间:2014-07-15 13:21 | 作者:童燕群
出处:http://shentar.me

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的读者做一次分享,到时您会来参加么?

via: InfoQ

相关 [jeff dean 在线] 推荐:

Jeff Dean的Stanford演讲

- zz - 酷壳 - CoolShell.cn
Google 公司的 Jeff Dean 在Stanford大学做了一个非常 精彩的演讲(视频未墙). 我觉得我们每一个人都应该去看一看这个视频,当然,没有字幕,需要不错的听力,当然,我不可能全部翻译出来,因为我也不是完全能听懂,下面是一些相关的Notes,供你参夸,并欢迎牛人指证. 比较了从1999年到2010年十年来的搜索量的变化.

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

- - 忘我的追寻
6月于硅谷举行的 Velocity 2014大会上,Google首席科学家Jeff Dean做了一场题为 《Achieving Rapid Response Times In Large Online Services》的主题演讲,分享了让大型系统运行更加流程以便改善用户体验的种种方法. Jeff首先以Google的搜索服务为例,说明了何为 大扇出服务(Large Fanout Service),即一个搜索请求需要有大量子系统(Web、新闻、图像、视频、博客等等)参与其中,以便提供更丰富的搜索结果.

Jeff Dean, 谷歌,软件系统,经验教训

- Amom - 弯曲评论
Jeff Dean, 谷歌院士,业界大牛,他的成就就不多介绍了,大家可以网上查查,但凡Google引以为豪的几个系统架构都少不了他. 本文是他在斯坦福演讲的Slides,谷歌的各类系统虽在Google Lab上些资料,但是由Jeff串讲一下也是受益匪浅,现Share给大家:. Youtube上有此次演讲的视频,大家可以去看看.

Jeff Dean关于Google系统架构的讲座

- water - 并行实验室 | Parallel Labs
上个月Jeff Dean在Standford的Computer Systems Colloquium (EE380)这门讨论课上详细讲了讲Google的系统架构发展过程,因为这是份很新的资料,所以特意把它的Slide下下来与大家分享一下. 这门课是Standford的讲座课程,每一节课都由不同的顶级工程师/科学家/投资人前来讲授IT行业的最新动向,非常非常有料,绝对值得深挖.

关于Jeff Dean的几个搞笑传言

- - 四火的唠叨
文章系本人原创,转载请保持完整性并注明出自 《四火的唠叨》. 我想许多程序员都对这个名字如雷贯耳,如果你没有听说过,可以扫一眼他的 个人履历,你会感到无比惊讶的:. Google AdSense(在线上发布广告);. Protocol Buffers协议,protobuf,用于把结构数据序列化;.

Jeff Bezos:一个营销员的诞生

- 小趴 八足趴 八足 ramener - 爱范儿 · Beats of Bits
Jeff Bezos 四岁的时候第一次去他祖父的奶牛场,位于德州 Cotulla 地区的一块 2 万 5 千英亩的土地. 他的祖父是一位退休的火箭科学家,决定放弃自己的研究,在农场过简单的生活,而他也想要将这个生活和它的孙子分享. 在 16 岁之前,Jeff 的每个夏天都在祖父的农场度过. 在这里,他学会了清理牲畜棚,阉割奶牛,安装水管等农场活计.

Jeff Bezos:后 PC 时代的强者

- bo - 爱范儿 · Beats of Bits
Jeff Bezos 的能量超过你的想象,对此, Steven Levy 有着切身的体会,他最近完成了对亚马逊 CEO 的一次专访. 后 PC 时代,平板成为各大公司争夺的目标. 在这场争夺未来的战争中,苹果公司的 iPad 遥遥领先;Google 的 Android 系统尚未突破;微软的平板系统仍需等待.

[译]Jeff Atwood:软件工程已死?

- - 呦呦鹿鸣
原文作者:Jeff Atwood. 2009年7月,Tom DeMarco在《IEEE Software》杂志上发表了一篇论文,题为“Software Engineering: An Idea Whose Time Has Come And Gone?”(软件工程:这个概念已经过时了. 我早年写过一本关于软件度量的书,书名叫《Controlling Software Projects: Management, Measurement, and Estimates》(由Prentice Hall出版社于1986年出版).

Amazon创始人Jeff Bezos的火箭试飞失败

- David - cnBeta.COM
感谢Bluehost中国的投递. 亚马逊创始人Jeff Bezos创办了航天公司Blue Origin, 该公司上周进行的一次亚轨道飞行器试飞以失败告终. Bezos在发布在官网的文章中说明了失败原因:发生故障时火箭的飞行高度是 45000英尺(约13.7公里),速度1.2马赫,飞行的不稳定使飞行器产生了攻角,触发了安全控制系统停止喷射.