信息检索

之前在公司内网看到fanli分享过该类的内容，里面提到了backup requests和canary requests，印象比较深刻，也是深有体会，

所以这里就转载下这篇文章，以便后续加深理解。

原文：

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

（备注：99%ile的含义：%ile means the percentage of people ranked below you）

针对延时问题，有些基本的降低延时的技术：

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

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

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

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

更多 >