分布式系统架构设计.docx

《分布式系统架构设计.docx》由会员分享，可在线阅读，更多相关《分布式系统架构设计.docx（23页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、本文作者Kate Matsudaira 是一位秀丽的女工程副总裁，曾在Sun Microsystems、微软、亚马逊这些一流的IT 公司任职。她有着格外丰富的工作阅历和团队治理阅历，当过程序员、工程经理、产品经理以及人事经理。专注于构建和操作大型Web 应用程序/网站，目前她的主要争论方向是SaaS软件即效劳应用程序和云计算如大家所说的大数据。本文是作者在AOSA 一书介绍如何构建可扩展的分布式系统里的内容，在此翻译并共享给大家。开源软件已经成为很多大型网站的根本组成局部，随着这些网站的逐步壮大，他们的网站架构和一些指导原则也开放在开发者们的面前，赐予大家切实有用的指导和帮助。这篇文章主要侧重

2、于Web 系统，并且也适用于其他分布式系统。Web 分布式系统设计的原则构建并运营一个可伸缩的Web 站点或应用程序到底是指什么？在最初，仅是通过互联网连接用户和访问远程资源。和大多数事情一样，当构建一个Web 效劳时，需要提前抽出时间进展规划。了解大型网站创立背后的留意事项以及学会权衡，会给你带来更加明智的决策。下面是设计大型Web 系统时，需要留意的一些核心原则： 可用性 性能 牢靠性 可扩展 易治理 本钱上面的这些原则给设计分布式Web 架构供给了肯定的根底和理论指导。然而，它们也可能彼此相左，例照实现这个目标的代价是牺牲本钱。一个简洁的例子：选择地址容量，仅通过 添加更多的效劳器可伸缩

3、性，这个可能以易治理你不得不操作额外的效劳器和本钱作为代价效劳器价格。无论你想设计哪种类型的Web 应用程序，这些原则都是格外重要的，甚至这些原则之间也会相互羁绊，做好它们之间的权衡也格外重要。根底当涉及到系统架构问题时，这几件事情是必需要考虑清楚的：什么样的模块比较适宜？如何把它们组合在一起？如何进展恰当地权衡？在扩大投资之前，它通常需要的并不是一个精明的商业命题，然而，一些深谋远虑的设计可以帮你在将来节约大量的时间和资源。本文争论的重点几乎是构建全部大型Web 应用程序的核心：效劳、冗余、分区和故障处理力量。这里的每个因素都会涉及到选择和妥协，特别是前面所争论的那些原则。解释这些核心的最正

4、确方法就是举例子。图片托管应用程序有时，你会在线上传图片，而一些大型网站需要托管和传送大量的图片，这对于构建一个具有本钱效益、高可用性并具有低延时快速检索的架构是一项挑战。在一个图片系统中，用户可以上传图片到一个中心效劳器里，通过网络连接或API 对这些图片进展恳求，就像Flickr 或者Picasa。简洁点，我们就假设这个应用程序只包含两个核心局部：上传写图片和检索图片。图片上传时最好能够做到高效，传输速度也是我们最关心的，当有人向图片发出恳求时例如是一个Web 页面或其他应用程序。这是格外相像的功能，供给Web 效劳或内容分发网络一个CDN 效劳器可以在很多地方存储内容， 所以无论是在地理

5、上还是物理上都更加接近用户，从而导致更快的性能边缘效劳器。该系统需要考虑的其他重要方面：图片存储的数量是没有限制的，所以存储应具备可伸缩，另外图片计算也需要考虑下载/恳求需要做到低延迟用户上传一张图片，那么图片就应当始终在那里图片数据的牢靠性 系统应当易于维护易治理由于图片托管不会有太高的利润空间，所以系统需要具备本钱效益图 1 是个简化的功能图图 1 图片托管系统的简化构造图在这个例子中，系统必需具备快速、数据存储必需做到牢靠和高度可扩展。构建一个小型的应用程序就微缺乏道了，一台效劳器即可实现托管。假设这样，这篇文章就毫无兴趣和吸引力了。假设我们要做的应用程序会渐渐成长成Flickr 那么大

6、。效劳当我们考虑构建可伸缩的系统时，它应有助于解耦功能，系统的每个局部都可以作为自己的效劳并且拥有清楚的接口定义。在实践中，这种系统设计被称作面对效劳的体系构造SOA。对于此类系统，每个效劳都有它自己的独特功能，通过一个抽象接口可以与外 面的任何内容进展互动，通常是面对公众的另一个效劳API。把系统分解成一组互补性的效劳，在相互解耦这些操作块。这种抽象有助于在效劳、根本环境和消费者效劳之间建立格外清楚的关系。这种分解可以有效地隔离问题，每个块也可以相互伸缩。这种面对效劳的系统设计与面对对象设计格外相像。在我们的例子中，全部上传和检索恳求都在同一台效劳器上处理。然而，由于系统需要具备可伸缩性，所

7、以把这两个功能打破并集成到自己的效劳中是有意义的。快进并假设效劳正在大量使用；在这种状况下，很简洁看到写图片的时间对读图片时间会产 生多大影响他们两个功能在彼此竞争共享资源。依据各自体系，这种影响会是巨大的。即使上传和下载速度一样这是不行能的，对于大多数的IP 网络来说，下载速度：上传速度至少是 3:1，通常，文件可以从缓存中读取，而写入，最终是写到磁盘中或许在最终全都的状况下，可以被多写几次。即使是从缓存或者磁盘类似SSD中读取，数据写 入都会比读慢Pole Position，一个开源DB 基准的开源工具和结果。这种设计的另一个潜在问题是像Apache 或者Lig d 这些Web 效劳器通常

8、都会有一个并发连接数上限默认是500，但也可以更多，这可能会花费高流量，写可能会快速消掉所 有。既然读可以异步或利用其他性能优化，比方gzip 压缩或分块传输代码，Web 效劳可以快速切换读取和客户端来效劳于更多的恳求，超过每秒的最大连接数Apache 的最大连接数设置为 500，这种状况并不常见，每秒可以效劳几千个读取恳求。另一方面，写通常倾向于保持一个开放的链接进展持续上传，所以，使用家庭网络上传一个 1 MB 的文件花费的时间可能会超过 1 秒，所以，这样的效劳器只能同时满足500 个写恳求。图 2：读取分别规划这种瓶颈的一个格外好的做法是把读和写进展分别，如图2 所示。这样我们就可以对

9、 它们单独进展扩展始终以来读都比写多但也有助于弄明白每个点的意思。这种分别更易于排解故障和解决规模方面问题，如慢读。这种方法的优点就是我们能够彼此独立解决问题在同种状况下，无需写入和检索操作。这两种效劳仍旧利用全球语料库的图像，但是他们可以自由地优化性能和效劳方法例如排 队恳求或者缓存流行图片下面会介绍更多。从维护和本钱角度来看，每一个效劳都可 以依据需要独立进展扩展，但假设把它们进展合并或交织在一起，那么有可能无意中就会对 另一共性能产生影响，如上面争论的情景。固然，假设你有两个不同的端点，上面的例子可能会运行的很好事实上，这格外类似于几个云存储供给商之间的实现和内容分发网络。虽然有很多种方

10、法可以解决这些瓶颈，但每个人都会有不同的权衡，所以承受适合你的方法才是最重要的。例如，Flickr 解决这个读/写问题是通过分发用户跨越不同的碎片，每个碎片只能处理一组用户，但是随着用户数的增加，更多的碎片也会相应的添加到群集里请参阅 Flickr 的扩展介绍。在第一个例子中，它更简洁基于硬件的实际用量进展扩展在整个系统中的读/写数 量，而Flickr 是基于其用户群进展扩展(but forces the assumption of equal usage across users so there can be extra capacity)。而前面的那个例子，任何一个中断或者问题都会降低整

11、个系统功能例如任何人都没方法执行写操作，而Flickr 的一个中断只会影响到其所在碎片的用户数。在第一个例子中，它更简洁通过整个数据集进展操作例如，更写服 务，包括的元数据或者通过全部的图片元数据进展搜寻而 Flickr 架构的每个碎片都需要被更或搜寻或者需要创立一个搜寻效劳来收集元数据事实上，他们就是这样做 的。当谈到这些系统时，其实并没有格外正确的答案，但有助于我们回到文章开头处的原则上看 问题。确定系统需求大量的读或写或者两个都进展、级别并发、跨数据查询、范围、种类等等，选择不同的基准、理解系统是如何出错的并且对以后的故障发生状况做些扎实的计 划。冗余为了可以正确处理错误，一个Web 架

12、构的效劳和数据必需具备适当的冗余。例如，假设只有一个副本文件存储在这台单独的效劳器上，那么假设这台效劳器消灭问题或丧失，那么该文件也随即一起丧失。丧失数据并不是什么好事情，避开数据丧失的常用方法就是多创立几个文件或副本或冗余。同样也适用于效劳器。假设一个应用程序有个核心功能，应确保有多个副本或版本在同时运行，这样可以避开单节点失败。在系统中创立冗余，当系统发生危机时，假设需要，可以消退单点故障并供给备份或备用功 能。例如，这里有两个一样的效劳例如在生产环境中运行，假设其中一个发生故障或者降低， 那么该系统容错转移至那个安康的副本上。容错转移可以自动发生也可以手动干预。效劳冗余的另一重要组成局部

13、是创立一个无共享架构。在这种体系构造中，每个节点都能相 互独立运行，并且没有所谓的中心“大脑”治理状态或协调活动其他节点。这对系统的可扩展帮助很大，由于节点在没有特别要求或学问的前提下被添加。然而，最重要的是，这些系统是没有单点故障的，所以失败的弹性就更大。例如在我们的图片效劳器应用程序中，全部的图片在另一个硬件上都有冗余副本抱负状况 下是在不同的地理位置，避开在数据中心发生一些火灾、地震等自然事故，效劳去访问图片将被冗余，全部潜在的效劳恳求。参见图3：承受负载均衡是实现这点的最好方法，在下面还会介绍更多方法图 3 图片托管应用程序冗余分区数据集有可能格外大，无法安装在一台效劳器上。也有可能这

14、样，某操作需要太多的计算资 源、性能降低并且有必要增加容量。在这两种状况下，你有两种选择：纵向扩展或横向扩展。纵向扩展意味着在单个效劳器上添加更多的资源。所以，对于一个格外大的数据集来说，这可能意味着添加更多或更大的硬件设备，来使一台效劳器能容下整个数据集。在计算操作下，这可能意味着移动计算到一个更大的效劳器上，拥有更快的CPU 或更大的内存。在各种状况下，纵向扩展可以通过提升单个资源的处理力量来完成。横向扩展在另一方面是添加更多的节点，在大数据集下，这可能会使用其次效劳器来存储部 分数据集，对于计算资源来说，这意味着分割操作或跨节点加载。为了充分利用横向扩展， 它应作为一种内在的系统架构设计

15、原则，否则修改或拆分操作将会格外麻烦。当谈到横向扩展时，最常见的做法是把效劳进展分区或碎片。分区可以被派发，这样每个逻 辑组的功能就是独立的。可以通过地理界限或其他标准，如非付费与付费用户来完成分区。这些方案的优点是他们会随着容量的增加供给一个效劳或数据存储。在我们的图片效劳器案例中，用来存储图片的单个文件效劳器可能被多个文件效劳器取代， 每个里面都会包含一套自己独特的图像。见图 4这种架构将允许系统来填充每一个文件/图片效劳器，当磁盘填满时会添加额外的效劳器。这样的设计需要一个命名方案，用来捆 绑图片文件名到其相应的效劳器上。图像名字可以形成一个全都的哈希方案并映射到整个效劳器上；或者给每张

16、图片安排一个增量ID，当客户端对图片发出恳求时，图片检索效劳只 需要检索映射到每个效劳器上例如索引的ID。图 4 图片托管应用程序冗余和分区固然，跨越多个效劳器对数据或功能进展分区还是有很多挑战的。其中的关键问题是数据本 地化。在分布式系统中，数据操作或计算点越接近，系统性能就会越好。因此，它也可能是个潜在问题，当数据分散在多个效劳器上时。有时数据不是在本地，那么就要迫使效劳器通 过网络来猎取所需的信息，这个猎取的过程就会设计到本钱。另一潜在问题是不全都。当这里有多个效劳对一个共享资源执行读写操作时，潜在可能会有另一个效劳器或数据存储参与进来，作为竞选条件一些数据需要更，但是读的优先级高于更在

17、这种状况下，数据就是不全都的。例如在图片托管方案中，有可能消灭的不全都是：假设一个客户端发送更“狗”图片恳求，进展重命名，把“Dog”改成“Gizmo”，但同时，另一个客户端正在读这张图片。在这种状况下，标题就是不清楚的。“Dog”或“Gizmo” 应当被其次个客户端接收。固然，在进展数据分区时会产生一些障碍，但是分区允许把每个问题拆分到治理群里通 过数据、负载、使用模式等。这样对可扩展和易治理都是有帮助的，但也不是没有风险的。这里有很多方式来降低风险和故障处理；然而，为了简便起见，并未在本文中具体说明，如 果你有兴趣，可以访问我的博客。总结以上介绍的都是设计分布式系统需要考虑的核心要素。可用

18、性、性能、牢靠性、可扩展、易治理、本钱这几个原则格外重要，但在实际应用中可能会以牺牲某个原则来实现另外一个原则， 在这个过程中就要做好权衡工作，做到因时制宜。在下面的构建分布式系统实战中，我们将会深入介绍如何设计可扩展的数据访问，包括负载均衡、代理、全局缓存、分布式缓存等。摘要：在上一篇构建高可扩Web 架构和分布式系统实战中，我们举例争论了设计分布式系统需要考虑的核心要素：可用性、性能、牢靠性、可扩展、易治理、本钱。而在这篇文章中，我们将深入介绍如何设计可扩展的数据访问，包括负载均衡、代理、全局缓存、分布式缓存等。本文作者Kate Matsudaira 是一位秀丽的女工程副总裁，曾在Sun

19、Microsystems、微软、亚马逊这些一流的IT 公司任职。她有着格外丰富的工作阅历和团队治理阅历，当过程序员、工程经理、产品经理以及人事经理。专注于构建和操作大型Web 应用程序/网站，目前她的主要争论方向是SaaS软件即效劳应用程序和云计算如大家所说的大数据。本文是作者在AOSA 一书介绍如何构建可扩展的分布式系统里的内容，我们进展了翻译并分为上下两篇分布共享给大家。在上一篇构建高可扩 Web 架构和分布式系统实战中， 我们举例争论了设计分布式系统需要考虑的核心要素：可用性、性能、牢靠性、可扩展、易治理、本钱。而在这篇文章中，我们将深入介绍如何设计可扩展的数据访问，包括负载均衡、代理、

20、全局缓存、分布式缓存等。构建快速可伸缩的数据访问块在争论完设计分布式系统的核心考虑因素后，下面让我们再一起争论难点局部：可扩展的数据访问。大多数简洁的Web 应用程序，例如LAMP 堆栈应用程序，看起来如图5 所示：图 5：简洁的Web 应用程序随着系统渐渐扩大，他们将面临两大主要挑战：构建可扩展的应用程序效劳器和数据访问机制。在一个高可扩的应用程序设计中，通常最小化的应用程序或Web效劳往往能表达 一种无共享的架构。这就使得应用程序效劳器层要进展横向扩展，这种设计的结果就是把繁重的工作转移到堆栈下层的数据库效劳和配置效劳上，这才是这一层上真正的可扩展和性能挑战。本文的剩余局部特地争论一些常见

21、策略和方法来使这些效劳可以快速和可扩展，提升数据的访问速度。图 6 过于简化的的Web 应用程序大多数系统可能会简化成图 6 那样，这是个格外不错的起点。假设你有大量的数据，想要快速便捷地访问，就好比在你书桌抽屉的最上面有一堆糖果。虽然过于简化，但也示意了两个难题：可扩展存储和快速的数据访问。为了这个例子，让我们假设有很多太字节TB数据，并且允许用户随机访问一小局部数据见图 7。这与本文图片应用程序里的在文件效劳器上定位一个图片文件格外相像。图 7 访问特定数据这也是个格外大的挑战，把 TB 级数据加载到内存中的本钱比较昂贵，这可以直接转化到磁盘上进展IO。从磁盘上读取要比内存慢的多内存访问和

22、 Chuck Norris 一样快，而磁盘的访问速度要比在DMV 上慢。这个速度不同于大数据集上的合计，实数内存访问或许要比挨次访问快 6 倍，或者比随机从磁盘上读取快 10 万倍参考 The Pathologies of Big Data。此外，即使是unique ID，想要在较少的数据中查找精准的位置也是一项困难的任务。幸运的是，能找到很多方法让这个问题变的简洁，这里供给4 个格外重要的方法：缓存、代理、索引和负载均衡器。在下面将会具体争论这4 个内容来提升数据访问速度。缓存缓存就是利用本地参考原则：当CPU 要读取一个数据时，首先从缓存中查找，找到就马上读取并送给CPU 处理；没有找到，

23、就用相对慢的速率从内存中读取并送给CPU 处理，同时把这个数据所在的数据块调入缓存中，可以使得以后对整块数据的读取都从缓存中进展， 不必再调用内存。它们几乎被用在每一个计算层上：硬件、操作系统、Web 扫瞄器、Web 应用程序等。一个缓存就相当于是一个临时内存：它有一个有限的空间量，但访问它比访问 原始数据速度要快。缓存也可以存在于各个层的架构中，但常常在离前端最近的那个层上发 现，在那里可以快速实现并返回数据，无需占用下游层数据。那么如何在我们的API 例子里利用缓存使数据访问更快呢？在这种状况下，有很多地方可以插入缓存。一种是在恳求层节点上插入缓存，如图8 所示。图 8 在恳求层节点插入缓

24、存在恳求层节点上放置一个缓存，即可响应本地的存储数据。当对效劳器发送一个恳求时，假设本地存在所恳求数据，那么该节点即会快速返回本地缓存数据。假设本地不存在，那么恳求节点将会查询磁盘上的数据。恳求层节点缓存即可以存在于内存中这个格外快速也可以位于该节点的本地磁盘上比访问网络存储要快。图 9 多个缓存当扩展到很多节点的时候，会发生什么呢？如图9 所示，假设恳求层被扩展为多个节点， 它仍旧有可能访问每个节点所在的主机缓存。然而，假设你的负载均衡器随机分布节点之间的恳求，那么恳求将会访问各个不同的节点，因此缓存遗漏将会增加。这里有两种方法可以抑制这个问题：全局缓存和分布式缓存。全局缓存顾名思义，全局缓

25、存是指全部节点都使用同一个缓存空间。这包含添加一台效劳器或某种类型的文件存储，全部恳求层节点访问该存储要比原始存储快。每个恳求节点会以同种方式查询缓存，这种缓存方案可能有点简单，随着客户机和恳求数量的增加，单个缓存Cache很简洁溢出，但在某些构造中却是格外有效的特别是那些特定的硬件，特地用来提升全局缓存速度，或者是需要被缓存的特定数据集。在图 10 中描述了全局缓存常见的两种方式。当一个Cache 响应在高速缓存中没有觉察时， Cache 自己会从底层存储中检索缺少的那块数据。如图11 所示，恳求节点去检索那些在高速缓存中没有觉察的数据。图 10 负责检索数据的全局缓存图 11 全局缓存里负

26、责检索的恳求节点大多使用全局缓存的应用程序都倾向于使用第一种类型，利用Cache 本身来驱除和猎取数据以防止来自客户端的同一个数据区发出大量的恳求。然而，在某些状况下，使用其次种实现反而更有意义。例如，假设该缓存用于存储大量的文件，低缓存的命中率会导致高速缓冲区不堪重负和缓存遗漏，在这种状况下， it helps to have a large percentage of the total data set (or hot data set) in the cache.分布式缓存分布式缓存即缓存在分布式系统各节点内存中的缓存数据。如图12 所示，每个节点都有自己的缓存数据，所以假设冰箱扮演着

27、缓存杂货店的角色，那么分布式缓存就是把食物放置在 不同的地方冰箱、橱柜和饭盒当索取的时候，便利拿哪个就拿哪个，而无需特地往 商店跑一趟。通常状况下，会使用全都性哈希函数对缓存进展划分，例如，一个恳求节点正 在查找一个特定块的数据，在分布式缓存中，它很快就会知道去哪里找，并确保这些数据是 可用的。这种状况下，每个节点都会有一小块缓存，然后在向另一个节点发送数据恳求。因此分布式缓存的优点之一就是只需向恳求池添加节点即可增加缓存空间，削减对数据库的访 问负载量。固然，分布式缓存也存在缺点，例如单点实效，当该节点消灭故障或宕机，那么该节点保存的数据就会丧失。图 12 分布式缓存分布式缓存的突出优点是提

28、高运行速度前提固然是正确实现。选择不同的方法也会有不 一样的效果，假设方法正确，即使恳求数很多，也不会对速度有所影响。然而，缓存的维护需要额外的存储空间，这些通常需要购置存储器实现，但价格都很昂贵。其中一个格外流行的开源缓存产品：Memcached即可以在本地缓存上工作也可以在分布 式缓存上工作；然而，这里还有很多其他选项包括很多语言或者是框架特定选项。Memcached 用于很多大型Web 站点，其格外强大。Memcached 基于一个存储键/值对的hashmap，优化数据存储和实现快速搜寻O(1)。Facebook 承受不同类型的缓存技术来提升他们的网站性能参考“Facebook cach

29、ing and performance”。在语言层面上使用$GLOBALS 和 APC在PHP 里供给函数调用，这有助于使中间函数调用更快大多数语言都使用这些类型库来提升网站页面性能。Facebook 使用全局缓存并且通过多台效劳器对缓存进展分布参考“Scaling memcached at Facebook”，这就允许他们通过配置用户文件数据来获得更好的性能和吞吐量，并且还可 以有一个中心位置更数据这是格外重要的，当运行成千上万台效劳器时，缓存实效和一 致性维护都是格外大的挑战。下面让我们谈谈当数据不在缓存中时，我们该做什么 代理简洁点讲，代理效劳器就是硬件/软件的中间件，承受客户端恳求并且

30、将他们转发到后端的源效劳器上。通常，代理效劳器用于过滤恳求、记录恳求日志或有时转换恳求通过添加/ 删除头结点、加密/解密或压缩。图 13 代理效劳器代理可以优化恳求，并且从整个系统的角度来优化恳求通信量。一方面，使用代理可以加速 数据访问，可以把一样或相像的恳求重叠压缩成一个恳求，然后返回单个结果到恳求客户端，这就是压缩转发collapsed forwarding。在一个局域网代理中，例如，客户端无需使用它们自己的IP 去连接互联网，对于一样的内容，局域网将压缩来自客户端的恳求。它很简洁造成混淆，由于很多代理同样也是缓存它是一个格外符合规律放置缓存的地方，但并非全部缓存都扮演代理这一角色。图

31、14 使用一个代理效劳器压缩恳求使用代理效劳器的另一宏大方式是通过压缩恳求对空间数据进展加密。承受这种策略最大化数据本地化的恳求会导致削减恳求的延迟。例如这里有一大串的节点恳求B：partB1、partB2等等。我们可以设置代理来识别个人空间的位置恳求，把它们压缩成单一的恳求并只返回bigB，大大削减了从数据源处读取数据次数如图15 所示。在高负载的状况下，代理也特别有用，或者当你具有有限的缓存时，它们根本上可以把多个恳求批处理成一个。图 15 使用代理对空间数据恳求进展压缩假设你正在为系统查找代理，这里供给几个供你选择：Squid 和Varnish，它们都做过格外全面的测试并且被广泛用在很多

32、大型网站上。这些代理解决方案对客户端效劳器端通信供给了很多优化方案。在Web 效劳器层作为反向代理安装可以大大提高Web 效劳性能， 削减处理传入客户机恳求所需的工作量。索引使用索引来快速访问和优化数据是一个众所周知的策略，最知名的莫过于数据库索引。图 16 索引一个索引就是数据库表的名目，表中数据和相应的存储位置的列表。好比是一篇文章的名目，可以加快数据表的。例如让我们来查找一块数据，B 中的其次局部如何觉察它的位置？ 假设你通过数据类型存储了一个索引例如数据 A、B、C它将告知你数据B 的原始位置。然后你只需去查看B 并且依据需要阅读B 的数据即可参考图 16。这些索引通常存储在内存或者是

33、传入客户端恳求的本地中。Berkeley DBsBDBs和树数据构造常常被用在有序列表中存储数据，这是访问索引的抱负选择。通常，会把很多层索引作为一个映射，从一个位置移到下一个，以此类推，直到你得到想要的特定块数据参照图 17。图 17 多层索引索引也可以对一样的数据创立多个不同的视图。对大型数据集来说，这种方法是格外好的， 无需创立多个额外的数据副本就可以定义不同的过滤和排序，例如，早期的图像托管系统实际上是托管图像书本内容，允许客户端查询这些图像中的内容， 输入一个主题，就可以把全部相关的内容搜寻出来。此外，承受同样的方式，搜寻引擎还允 许你搜寻出HTML 内容。在这种状况下，需要很多的效

34、劳器来存储这些文件，查找其中一个页面可能会很麻烦。首先，反向索引查询任意个单词或字元祖都需要可以轻松地访问；再 有就是导航到正确的页面和位置，检索到正确的图像结果也是项挑战。因此，在这种状况下， 反向索引会映射到一个位置例如书B，然后书B 可能会有一个包含全部内容、位置和各个局部消灭次数的索引。这种中间级索引只包含了Words、位置和书B 的信息。与全部的信息不得不存储到一个大的反向索引中相比，这种嵌套的索引架构允许每个索引占用较少的空间。在大型系统中，这是格外关键的，即使承受压缩，这些索引也需要占用相当昂贵的存储空间。例如，让我们假设这个世界上有100,000,000 本书参考Inside

35、Google Books 官方博客每本书只有 10 页，每页只有 250 个单词，这也就意味着有 2500 亿个单词。假设每个单词只有 5 个字节，每个字节占用8 bits或 1 个 byte，甚至有些字符占用2 bytes， 所以 5 bytes/单词，那么一个索引所包含的单词就有可能超过一个TB 的存储。此外，索引还有可能包含其他信息，例如元祖单词、数据位置等。能够快速、轻松地找到数据是格外重要的，而使用索引就可以简洁高效的实现。负载均衡器分布式系统的另一个关键局部是负载均衡。负载均衡器几乎是每个架构的主要组成局部，他们的角色是负责把网络恳求分散到一个效劳器集群中的可用效劳器上去，通过治理

36、进入的Web 数据流量和增加有效的网络带宽，从而使网络访问者获得尽可能最正确的联网体验的硬件设备。图 18 负载均衡器这里有很多种算法可用于为恳求供给效劳，包括随机选择一个节点、循环或者甚至是基于某个特定的标准来选择节点，例如内存或CPU 利用率。负载均衡器即可以以硬件的方式表现出来，也可以以软件的方式。HAProxy 是一个开源的负载均衡器，并且得到了格外广泛的使用。在一个分布式系统中，负载均衡器通常处于系统的前端位置，全部传入的恳求会相应地被路由。在一个简单的分布式系统中，一个恳求被路由到多个负载均衡器上并不常见，如图19 所示：图 19 多个负载平衡器和代理一样，有些负载均衡器也可以基于

37、恳求的类型路由到不同的效劳器集群上。技术上来讲，这也被称为反向代理。负载均衡器所面临的挑战之一是治理用户特有的会话user-session-specific数据。在一个电子商务网站上，当你只有一个客户端时，是很简洁让用户把商品放入购物车并且连续访 问这是格外重要的，由于商品很有可能在连续出售，而用户退出时，商品仍旧留在购物车 里。然而，假设用户本次会话路由了一个节点，那么当他下次访问的时候会路由一个不同的节点，这样，就很有可能使购物车里的商品不全都，由于的节点有可能会丧失该用户购 物车里原先的商品当你先放 6 包 Mountain Dew 在购物车里，等到再次登录后觉察购物车为空了。解决这个问

38、题的方法之一是使用sticky sessions，来使用户始终被路由到一样的节点，但它很难利用到牢靠性功能，像自动故障转移automatic failover。这种状况下， 用户的购物车里将会始终有商品，但假设sticky node 变的不行用，这就需要特别状况来处理并且假设购物车里的商品将不再有效尽管期望这种假设不会被内置于应用程序里。当 然解决这个问题还有很多其他方法，例如本文提到的效劳以及不包括扫瞄器缓存、cookies 和 URL 重写。在一个大型系统里会有各种不同类型的调度和负载均衡算法，包括简洁点的像随机选择或循 环以及更简单的机制，例如利用率和容量。全部的这些算法都可以分布流量和

39、恳求，并且提 供有用的牢靠性工具，像自动故障转移或者自动去除一个坏的节点例如当它无法响应时。然而，这种高级功能会把问题诊断的简单。 例如，当遇到高负载状况时，负载均衡器将会移除变慢或超时的节点由于恳求太多，删除节点后会把恳求安排到其他节点上，这无疑 会加剧其他节点的工作量，即负载加重。这种状况下，大量的监测变的格外重要，由于整个 系统流量和吞吐量看起来可能会削减由于节点效劳更少的恳求，但可能会累坏个别节点处理更多的恳求。负载均衡器也是扩展系统容量的一种简洁方式，像文中提到的其他技术，在分布式系统架构 中发挥着格外重要的作用。负载均衡器也供给一些重要功能来测试节点的安康状况，例如， 假设该节点响

40、应迟钝或过载，它可能就会被删除，然后利用系统中不同的节点冗余。队列到目前为止，我们已经争论了很多方法来加快数据读取速度，但扩展数据层的另一个重要组 成局部是如何高效的写入数据。在简洁的系统中，进程负载等都比较少，并且数据库比较小， 毋庸置疑，写的速度确定不会慢。然而，在大型简单的系统里，这个速度就很难把握了，可能会花费很长的时间。例如，数据有可能要写到几个不同的地方，不同的效劳器或索引、或 者系统正处于高负载状况下。在这种状况，该在哪里进展写？或者其他任何任务都有可能花 费很长时间，要想在系统实现性能和可用性需要构建异步。处理这种异步的一种常见的方式 就是承受队列。图 20 同步恳求想象在一个

41、系统里，每个客户机都要把恳求发送至远程效劳器，那么效劳器应当尽可能快的接收并完成任务，然后把结果返回到相应的客户端。在小型系统中，一台效劳器或规律效劳器传入客户端数据会与客户端发出时一样快，这样就比较完善了。然而，当效劳器接收到的恳求多余它的处理力量时，那么每个客户端必需排队等待效劳器处理其他客户端恳求， 直到轮到你了，效劳器才会处理你的恳求，直到最终完成。这就是一个同步恳求的例子，如图 20 所示。这种同步行为会严峻降低客户端性能，客户端被迫等待，而通过添加额外的效劳器来满足负载并不能解决问题，即使承受最有效的负载均衡也很难保证安排公正，在大客户端下。进一步讲，假设处理恳求的效劳器不行用或者

42、瘫痪，那么客户端上游也将失败。有效的解决这个问题需要抽象客户端恳求以及效劳恳求的实际工作。图 21 使用队列来治理恳求队列就像听起来那样简洁，一个任务进来，就添加到队列里去，然后the workers 选择有力量处理的下一个任务。参考图 21这些任务有可能仅是简洁的写入，也有可能是简单的， 如把文档生成图像预览。当一个客户端把任务恳求提交的队列中时，他们不需要被迫等待结 果，相反，他们只需确认恳求是否被正确接收。队列使客户端能够以异步的方式工作，对客户端恳求和响应供给战略抽象。另一方面，在一 个同步系统中，恳求和回应是没有分化的，因此他们不能被分开治理。在异步系统中，客户端发出恳求任务，效劳器

43、对收到的消息进展响应并确认任务被接收，然后客户端可以定期检 查任务状态，一旦任务完成，即可看到结果。当客户端在等待异步恳求是否完成时，它还可以自由执行其他任务，甚至是向其他效劳器发出异步恳求。下面要介绍的是消息和队列在分 布式系统中的杠杆作用。队列也对效劳中断或失败供给一种保护机制。例如，它很简洁创立一个高度强健的队列，当效劳器瞬间失败时，该队列可以把刚刚失败的恳求重发送至效劳器。相比直接暴露客户端来连续效劳供给，使用队列来保证效劳质量更可取，要求必需有简单且冲突性的客户端过失处理。队列是治理分布式通信与任何大规模分布式系统中各个局部之间的根底，并且有很多实现方式。这里有很多开源的队列，如RabbitMQ、ActiveMQ、BeanstalkD，但也有一些当做效劳使用，如Zookeeper，甚至是用来数据存储，像Redis。总结设计出一个高效的分布式系统是令人兴奋的事情，尤其是拥有快速的数据访问速度。本文只是争论了几个实际的例子，期望对你能有所帮助。