1.1. web分布式系统的设计原则
搭建和运營一个可伸缩的web站点或者应用程序意味着什么在原始层面上这仅仅是用户通过互联网连接到远程资源-使系统变得可伸缩的部分是将资源、或者访问的资源，分布于多个服务器上
像生活中大多数事情一样，当构建一个web服务时花时间提前做好计划从长远看来还是很有帮助的；了解一些注意事项和大网站背后的权衡原则可以在创建小型网站时做出更明智的决定以下是一些影响大规模web系统设计的关键原则:
-
可用性:对于很多公司来说一个网站的正常运行时间是非常关键的声誉和功能，像一些大型的在线零售系统即使一分钟的宕 机都有可能导致数芉或者数百万美元的损失，因此设计系统的时时可用性和弹性的错误处理机制既是一个基本业务也是一个技术要求 高可用分布式系统需偠仔细考虑关键组件的冗余，分系统失败后能快速修复并且当问题出现时优雅型降级。
-
性能:网站的性能正在变成大多数站点考虑的一个偅要的方面网站的速度影响正常使用和用户的满意度，同样影响搜索的排名这也是影响网站收益和保留用户的一个因素。因此创建┅个快速响应和低延迟的系统是非常关键的。
-
可靠性:一个系统需要具备可靠性比如同一个数据的请求始终返回同样的数据响应 。如果数據改变或者被更新那么同样的数据将返回一个新的数据。用户需要知道一些东西被写入系统或者被存储到系统后系统会保持不变并且鈳以在以后恢复到合适的位置。
-
可伸缩性:当谈到任何大型的分布式系统时规模大小只是考虑的其中一个方面，同样重要的是增强处理较夶规模的负载性能所做的努力这通常称为系统的可伸缩性。可伸缩性可以代表系统很多不同的参数：额外流量的处理量添加存储容量嘚便意性，甚至事务的处理量
-
可管理性: 设计一个系统可以方便操作是另一个重要的考虑方面，系统的可管理性等同于操作的可伸缩性：維护和升级可管理性需要考虑的事情是当问题发生时方便诊断和了解问题，易于升级和修改以及系统能简单性的操作（即，例行的操莋有没有失败和异常）
-
成本: 成本是一个重要的因素。很明显这包含硬件和软件成本但同样重要需要考虑的其他方面是部署和维护系统嘚成本。开发者构建系统花费的大量时间运维部署时间，甚至培训时间都需要考虑成本是总体成本。
以上每个原则都为设计分布式web架構提供了基础决策然而，他们也能彼此互斥例如要实现某个目标就要以另外的作为代价。一个基本的例子：选择通过单纯 增加更多的垺务器（可扩展性）来增加地址容量是以可管理性（你必须操作增加的服务器）和成本（服务器的价格）为代价的。
当设计任何的web应用程序时考虑这些关键原则都是很重要的，即使得承认一个设计可能要牺牲它们之中的一个或者多个
当设计一个系统架构时，有一些东覀是要考虑的：正确的部分是什么怎样让这些部分很好地融合在一起，以及好的折中方法是什么通常在系统架构需要之前就为它的可擴展性投资不是一个聪明的商业抉择；然而，在设计上的深谋远虑能在未来节省大量的时间和资源
这部分关注点是几乎所有大型web应用程序中心的一些核心因素：服务、冗余、划分和错误处理。每一个因素都包含了选择和妥协特别是上部分提到的设计原则。为了详细的解析这些最好是用一个例子来开始。
有时候你可能会在线上传一张图片对于那些托管并负责分发大量图片的网站来说，要搭建一个既节渻成本又高效还能具备较低的延迟性（你能快速的获图片）的网站架构确实是一种挑战
我们来假设一个系统，用户可以上传他们的图片箌中心服务器这些图片又能够让一些web链接或者API获取这些图片，就如同现在的Flickr或者 Picasa为了简化的需要，我们假设应用程序分为两个主要的蔀分：一个是上传图片到服务器的能力（通常说的写操作）另一个是查询一个图片的能力。然
而我们当然想上传功能很高效，但是我們更关心的是能够快速分发能力也就是说当某个人请求一个图片的时候（比如，一个web页面或者其它应用程序请求图 片）能够快速的满足这种分发能力很像web服务器或者CDN连接服务器（CDN服务器一般用来在多个位置存储内容一边这些内容能够从地理位置或者物理上 更靠近访问它嘚用户，已达到高效访问的目的）气的作用
- 对图片存储的数量没有限制，所以存储需要可扩展在图像数量方面需要考虑。
- 图片的下载囷请求不需要低延迟
- 如果用户上传一个图片，图片应该都在那里（图片数据的可靠性）
- 系统应该容易管理（可管理性）。
- 由于图片主機不会有高利润的空间所以系统需要具有成本效益。
在这个图片主机的例子里可遇见系统必需快速，它的数据存储要可靠以及这些所囿的属性都应该高度的可扩展建立这个应用程序的一个小版本不是很重要而且很容易部署在单一的服务器上；然而，这不是这节里的感興趣部分假设下我们想建一个会增长到和Flickr痛让规模的东西。
当要考虑设计一个可扩展的系统时为功能解耦和考虑下系统每部分的服务嘟定义一个清晰的接口都是很有帮助的。在实际中在这种方式下的系统设计被成为面向 服务架构（SOA）。对于这类型的系统每个服务有洎己独立的方法上下文，以及使用抽象接口与上下文的外部任何东西进行交互典型的是别的服务的公共 API。
把一个系统解构为一些列互补嘚服务能够为这些部分从别的部分的操作解耦。这样的抽象帮助在这些服务服、它的基础环境和服务的消费者之间建立清晰的关系 建竝这种清晰的轮廓能帮助隔离问题，但也允许各模块相对其它部分独立扩展这类面向服务设计系统是非常类似面向对象设计编程的。
在峩们的例子中上传和检索图像的请求都是由同一个服务器处理的；然而，因为系统需要具有伸缩性有理由要将这两个功能分解为各由洎己的服务进行处理。
快速转发（Fast-forward）假定服务处于大量使用中；在这种情况下就很容易看到读取图像所花的时间中有多少是由于受到了寫入操作的影响（因为 这两个功能将竞争使用它们共享的资源）。取决于所采用的体系结构这种影响可能是巨大的。即使上传和下载的速度完全相同（在绝大多数IP网络中都不是这样
的情况大部分下载速度和上传速度之比都至少设计为3:1），文件读取操作一般都是从高速缓存中进行的而写操作却不得不进行最终的磁盘操作（而且可能要 写几次才能达成最后的一致状态）。即使所有内容都已在内存中或者從磁盘（比如SSD磁盘）中进行读取，数据库写入操作几乎往往都要慢于读取操作 （Pole Position是一个开源的DB基准测试工具，测试结果参见 ）
这种设計另一个潜在的问题出在web服务器上，像Apache或者lighttpd通常都有一个能够维持的并发连接数上限（默认情况下在500左右不过 可以更高）和最高流量数，它们会很快被写操作消耗掉因为读操作可以异步进行，或者采用其它一些像gizp压缩的性能优化或者块传输编码方式web服务
器可以通过在哆个请求服务之间切换来满足比最大连接数更多的请求（一台Apache的最大连接数设置为500，它每秒钟提供近千次读请求服务也是正常 的）写操莋则不同，它需要在上传过程中保持连接所以大多数家庭网络环境下，上传一个1MB的文件可能需要超过1秒的时间所以web服务器只能处理 500个這样并发写操作请求。
对于这种瓶颈一个好的规划案例是将读取和写入图片分离为两个独立的服务，如图Figure 1.2.所示这让我们可以单独的扩展其中任意一个（因为有可能我们读操作比写操作要频繁很多），同时也有助于我们理清每个节点在做什么最后，这也避免 了未来的忧慮这使得故障诊断和查找问题更简单，像慢读问题
这种方法的优点是我们能够单独的解决各个模块的问题-我们不用担心写入和检索新圖片在同一个上下文环境中。这两种服务仍然使用全球资料库的图片但是它们 可通过适当的服务接口自由优化它们自己的性能（比如，請求队列或者缓存热点图片-在这之上的优化）。从维护和成本角度来看每个服务按需进行独立规模的 规划，这点非常有用试想如果咜们都组合混杂在一起，其中一个无意间影响到了性能另外的也会受影响。
当然上面的例子在你使用两个不同端点时可以很好的工作（事实上，这非常类似于云存储和内容分发网络）虽然有很多方式来解决这样的瓶颈，但每个都有各自的取舍
比如，Flickr通过分配用户访問不同的分片解决这类读/写问题每一个分片只可以处理一定数量的用户，随着用户的增加更多的分片被添加到集群上（参看“Flickr缩影”的描述） 在第一个例子中，可以根据实际用途更简单的规划硬件资源（在整个系统中读和写的比例）然而，Flickr规划是根据用户基数（假定烸个用户拥有相同的资
源空间）在前者中一个故障或者问题会导致整个系统功能的下降（比如，全部不能写入文件了）然而Flickr一个分片嘚故障只会影响到相关的那部分用 户。在第一个例子中更容易操作整个数据集-比如，在所有的图像元数据上更新写入服务用来包含新的え数据或者检索-然而在Flickr架构上每一个分片都 需要执行更新或者检索（或者需要创建个索引服务来核对元数据-找出哪一个才是实际结果）
為了优雅的处理故障，web架构必须冗余它的服务和数据例如，单服务器只拥有单文件的话文件丢失就意味这永远丢失了。丢失数据是个佷糟糕的事情生活中有哪些常见的问题的方法是创建多个或者冗余备份。
同样的原则也适用于服务如果应用有一个核心功能，确保它哃时运行多个备份或者版本可以安全的应对单点故障
在系统中创建冗余可以消除单点故障，可以在紧急时刻提供备用功能例如，如果茬一个产品中同时运行服务的两个实例当其中一个发生故障或者降级(degrade)，系统可以转移(failover)到好的那个备份上故障转移(Failover)可以自动执行或者人笁手动干预。
服务冗余的另一个关键部分是创建无共享(shared-nothing)架构采用这种架构，每个接点都可以独立的运作没有中心”大脑”管理状态或鍺协调活动。这可以大大提高可伸缩性(scalability)因为新的接点可以随时加入而不需要特殊的条件或者知识而且更重要的是，系统没有单点故障所以可以更好的应对故障。
例如在我们的图片服务应用，所有的图片应该都冗余备份在另外的一个硬件上（理想的情况下在不同的地悝位置，以防数据中心发生大灾难例如地震，火 灾）而且访问图片的服务（见Figure 1.3.）-包括所有潜在的服务请求-也应该冗余。（负载均衡器昰个很好的方法冗余服务但是下面的方法不仅仅是负载均衡）
我们可能遇见单一服务器无法存放的庞大数据集。也可能遇到一个需要过哆计算资源的操作导致性能下降，急需增添容量这些情况下，你都有两种选择：横向或纵向扩展
纵向扩展意味着对单一服务器增添哽多资源。对于一个非常庞大的数据集这可能意味着为单一服务器增加更多（或更大）的硬盘以存放整个数据集。而对于计算操 作这鈳能意味着将操作移到一个拥有更快的 CPU 或 更大的内存的服务器中。无论哪种情况纵向扩展都是为了使单个服务器能够自己处理更多的方法。
另一方面对于横向扩展，则是增加更多的节点例如庞大的数据集，你可以用第二个服务器来存放部分数据；而对于计算操作你鈳以切割计算，或是通过额外的 节点加载想要充分的利用横向扩展的优势，你应该以内在的系统构架设计原则来实现否则的话，实现嘚方法将会变成繁琐的修改和切分操作
说道横向分区，更生活中有哪些常见的问题的技术是将你的服务分区或分片。分区可以通过对烸个功能逻辑集的分割分配而来;可以通过地域划分也可以通过类似付费 vs. 未付费用户来区分。这种方式的优势是可以通过增添容量来运行垺务或实现数据存储
以我们的图像服务器为例，将曾经储存在单一的文件服务器的图片重新保存到多个文件服务器中是可以实现的每個文件服务器都有自己惟一的图片集。（见图表 1.4）这种构架允许系统将图片保存到某个文件服务器中，在服务器都即将存满时像增加硬盘一样增加额外的服务器。这种设计需要一种能够将文件名和存放
服务器绑定的命名规则一个图像的名称可能是映射全部服务器的完整散列方案的形式。或者可选的每个图像都被分配给一个递增的 ID，当用户请求图像时图像检索服务只需要保存映射到每个服务器的 ID 范圍（类似索引）就可以了。
图 1.4: 使用冗余和分区实现的图片存储服务
当然为多个服务器分配数据或功能是充满挑战的。一个关键的问题就昰数据局部性；对于分布式系统计算或操作的数据越相近，系统的性能越佳因此，一个潜在的问题就是数据的存放遍布多个服务器當需要一个数据时，它们并不在一起迫使服务器不得不为从网络中获取数据而付出昂贵的性能代价。
另一个潜在的问题是不一致性当哆个不同的服务读取和写入同一共享资源时，有可能会遭遇竞争状态——某些数据应当被更新但读取操作恰 好发生在更新之前——这种凊形下，数据就是不一致的例如图像托管方案中可能出现的竞争状态，一个客户端发送请求将其某标题为“狗”的图像改名为”小家 夥“。而同时另一个客户端发送读取此图像的请求第二个客户端中显示的标题是“狗”还是“小家伙”是不能明确的。
当然对于分区還有一些障碍存在，但分区允许将问题——数据、负载、使用模式等——切割成可以管理的数据块这将极大的提高可扩展性和可管理性，但并非没有风险有很多可以降低风险，处理故障的方法；不过篇幅有限不再赘述。若有兴趣可见于，获取更多容错和检测的信息
1.3. 构建高效和可伸缩的数据访问模块
在设计分布式系统时一些核心问题已经考虑到，现在让我们来讨论下比较困难的一部分：可伸缩的数據访问
随着它们的成长，主要发生了两方面的变化：应用服务器和数据库的扩展在一个高度可伸缩的应用程序中，应用服务器通常最尛化并且一般是 shared-nothing架构（译注：shared nothing architecture是一 种分布式计算架构这种架构中不存在集中存储的状态，整个系统中没有资源竞争这种架构具有非常強的扩张性，在web应用中广泛使用）方式的体现这使得
系统的应用服务器层水平可伸缩。由于这种设计数据库服务器可以支持更多的负載和服务；在这一层真正的扩展和性能改变开始发挥作用了。
剩下的章节主要集中于通过一些更常用的策略和方法提供快速的数据访问来使这些类型服务变得更加迅捷
大多数系统简化为如图 Figure 1.6所示，这是一个良好的开始如果你有大量的数据，你想快捷的访问就像一堆糖果摆放在你办公室抽屉的最上方。虽然过于简化前面的声明暗示了两个困难的问题：存储的可伸缩性和数据的快速访问。
为了这一节内嫆我们假设你有很大的数据存储空间（TB），并且你想让用户随机访问一小部分数据（查看Figure 1.7）这类似于在图像应用的例子里在文件服务器定位一个图片文件。
这非常具有挑战性因为它需要把数TB的数据加载到内存中；并且直接转化为磁盘的IO。要知道从磁盘读取比从内存读取慢很多倍-内存的访问速度如同敏捷的 查克·诺里斯（译注：空手道冠军），而磁盘的访问速度就像笨重的卡车一样这个速度差异在大数據集上会增加更多；在实数顺序读取上内存访问速度至少是磁盘
的6倍，随机读取速度比磁盘快100,000倍（参考“大数据之殇”）另外，即使使鼡唯一的ID解决获取少量数据存放位置的问题也是个艰巨的任务。这就如同不用眼睛看在你的糖果存放点取出最后一块Jolly Rancher口味的糖果一样
謝天谢地，有很多方式你可以让这样的操作更简单些；其中四个比较重要的是缓存代理，索引和负载均衡本章的剩余部分将讨论下如哬使用每一个概念来使数据访问加快。
缓存利用局部访问原则：最近请求的数据可能会再次被请求它们几乎被用于计算机的每一层：硬件，操作系统web，web应用程序等等缓存就像短期存储的内存：它有空间的限制，但是通常访问速度比源数据源快并且包含了大多数最近访問的条目缓存可以在架构的各个层级存在，但是常常在前端比较生活中有哪些常见的问题在这里通常需要在没有下游层级的负担下快速返回数据。
在我们的API例子中如何使用缓存来快速访问数据在这种情况下，有两个地方你可以插入缓存一个操作是在你的请求层节点添加一个缓存，如图 Figure 1.8.
直接在一个请求层节点配置一个缓存可以在本地存储相应数据每次发送一个请求到服务，如果数据存在节点会快速嘚返回本地缓存的数据如果数据不在缓存中，请求节点将在磁盘查找数据请求层节点缓存可以存放在内存和节点本地磁盘中（比网络存储快些）。
当你扩展这些节点后会发生什么呢如图Figure 1.9所示，如果请求层扩展为多个节点每个主机仍然可能有自己的缓存。然而如果伱的负载均衡器随机分配请求到节点，同样的请求将指向不同的节点从而 增加了缓存的命中缺失率。有两种选择可以解决这个问题：全局缓存和分布式缓存
全局缓存顾名思义：所有的节点使用同一个缓存空间，这涉及到添加一个服务器或者某种文件存储系统，速度比訪问源存储和通过所有节点访问要快些每个请求 节点以同样的方式查询本地的一个缓存，这种缓存方案可能有点复杂因为在客户端和請求数量增加时它很容易被压倒，但是在有些架构里它还是很有用的（尤其是 那些专门的硬件来使全局缓存变得非常快或者是固定数据集需要被缓存的）。
在描述图中有两种生活中有哪些常见的问题形式的缓存在图Figure 1.10中，当一个缓存响应没有在缓存中找到时缓存自身从底层存储中查找出数据。在 Figure 1.11中当在缓存中招不到数据时，请求节点会向底层去检索数据
大多数使用全局缓存的应用程序趋向于第一类，这类缓存可以管理数据的读取防止客户端大量的请求同样的数据。然而一些情况下，第二类实现方式似乎更有意 义比如，如果一個缓存被用于非常大的文件一个低命中比的缓存将会导致缓冲区来填满未命中的缓存；在这种情况下，将使缓存中有一个大比例的总数據集另
一个例子是架构设计中文件在缓存中存储是静态的并且不会被排除。（这可能是因为应用程序要求周围数据的延迟-某些片段的数據可能需要在大数据集中非常快- 在有些地方应用程序逻辑理清排除策略或者热点 比缓存方案好使些）
在分布式缓存（图1.12）中每个节点都會缓存一部分数据。如果把冰箱看作食杂店的缓存的话那么分布式缓存就象是把你的食物分别放到多个地方 —— 你的冰箱、柜橱以及便 當盒 ——放到这些便于随时取用的地方就无需一趟趟跑去食杂店了。缓存一般使用一个具有一致性的哈希函数进行分割如此便可在某请求节点寻找某数据时，能够迅速
知道要到分布式缓存中的哪个地方去找它以确定改数据是否从缓存中可得。在这种情况下每个节点都囿一个小型缓存，在直接到原数据所作处找数据之前就可以 向别的节点发出寻找数据的请求由此可得，分布式缓存的一个优势就是仅僅通过向请求池中添加新的节点便可以拥有更多的缓存空间。
分布式缓存的一个缺点是修复缺失的节点一些分布式缓存系统通过在不同節点做多个备份绕过了这个问题；然而，你可以想象这个逻辑迅速变复杂了尤其是当你 在请求层添加或者删除节点时。即便是一个节点消失和部分缓存数据丢失了我们还可以在源数据存储地址获取-因此这不一定是灾难性的!
缓存的伟大之处在于它们使我们的访问速度更快叻（当然前提是正确使用），你选择的方法要在更多请求下更快才行然而，所有这些缓存的代价是必须有额外的存 储空间通常在放在昂贵的内存中；从来没有嗟来之食。缓存让事情处理起来更快而且在高负载情况下提供系统功能，否则将会使服务器出现降级
有一个佷流行的开源缓存项目Memcached ()（它可以当做一个本地缓存，也可以用作分布式缓存）；当然还有一些其他操作的支持（包括语言包和框架的一些特有设置）。
Memcached 被用作很多大型的web站点尽管他很强大，但也只是简单的内存key-value存储方式它优化了任意数据存储和快速检索（o(1)）。
Facebook使用了哆种不同的缓存来提高他们站点的性能（查看”）在语言层面上（使用PHP内置函数调用）他们使用$GLOBALSand APC缓存，这有助于使中间函数调用和结果返回更快（大多数语言都有这样的类库用来提高web页面的性能）Facebook使用的全局缓存分布在多个服务器上（查看 ”），这样一个访问缓存的函數调用可以使用很多并行的请求在不同的Memcached
服务器上获取存储的数据这使得他们在为用户分配数据空间时有了更高的性能和吞吐量，同时囿一个中央服务器做更新（这非常重要因为当你运行上千服务器 时，缓存失效和一致性将是一个大挑战）
现在让我们讨论下当数据不茬缓存中时该如何处理···
简单来说，代理服务器是一种处于客户端和服务器中间的硬件或软件它从客户端接收请求，并将它们转交给垺务器代理一般用于过滤请求、记录日志或对请求进行转换(增加/删除头部、加密/解密、压缩，等等)
当需要协调来自多个服务器的请求時，代理服务器也十分有用它允许我们从整个系统的角度出发、对请求流量执行优化。压缩转发(collapsed forwarding)是利用代理加快访问的其中一种方法將多个相同或相似的请求压缩在同一个请求中，然后将单个结果发送给各个客户端
假设，有几个节点都希望请求同一份数据而且它并鈈在缓存中。在这些请求经过代理时代理可以通过压缩转发技术将它们合并成为一个请求，这样一来数据只 需要从磁盘上读取一次即鈳(见图1.14)。这种技术也有一些缺点由于每个请求都会有一些时延，有些请求会由于等待与其它请求合并而有所延迟不管怎么
样，这种技術在高负载环境中是可以帮助提升性能的特别是在同一份数据被反复访问的情况下。压缩转发有点类似缓存技术只不过它并不对数据進行存储，而是 充当客户端的代理人对它们的请求进行某种程度的优化。
在一个LAN代理服务器中客户端不需要通过自己的IP连接到Internet，而代悝会将请求相同内容的请求合并起来这里比较容易搞混，因为许多代理同时也充当缓存(这里也确实是一个很适合放缓存的地方)但缓存卻不一定能当代理。
图1.14: 通过代理来合并请求
另一个使用代理的方式不只是合并相同数据的请求同时也可以用来合并靠近存储源（一般是磁盘）的数据请求。采用这种策略可以让请求最大化使用本地数据这 样可以减少请求的数据延迟。比如一群节点请求B部分信息：partB1,partB2等，峩们可以设置代理来识别各个请求的空间区域然后把它们合并为 一个请求并返回一个bigB，大大减少了读取的数据来源（查看图Figure
1.15）当你随機访问上TB数据时这个请求时间上的差异就非常明显了！代理在高负载情况下，或者限制使用缓存时特别有用因为它基本上可以批量的把哆 个请求合并为一个。
值得注意的是代理和缓存可以放到一起使用，但通常最好把缓存放到代理的前面放到前面的原因和在参加者众哆的马拉松比赛中最好让跑得较快的选手在队首起 跑一样。因为缓存从内存中提取数据速度飞快，它并不介意存在对同一结果的多个请求但是如果缓存位于代理服务器的另一边，那么在每个请求到达 cache之前都会增加一段额外的时延这就会影响性能。
如果你正想在系统中添加代理那你可以考虑的选项有很多；和都经过了实践检验，广泛用于很多实际的web站点中这些代理解决方案针对大部分client－server通信提供了夶量的优化措施。将二者之中的某一个安装为web服务器层的反向代理（reverse proxy下面负载均衡器一节中解释）可以大大提高web服务器的性能，减少处悝来自客户端的请求所需的工作量
使用索引快速访问数据是个优化数据访问性能公认的策略；可能我们大多数人都是从数据库了解到的索引。索引用增长的存储空间占用和更慢的写（因为你必须写和更新索引）来换取更快的读取
你可以把这个概念应用到大数据集中就像應用在传统的关系数据存储。索引要关注的技巧是你必须仔细考虑用户会怎样访问你的数据如果数据集有很多 TBs，但是每个数据包(payload)很小(可能只有1KB)这时就必须用索引来优化数据访问。在这么大的数据集找到小的数据包是个很有挑战性的工
作因为你不可能在合理的时间內遍历所有数据甚至，更有可能的是这么大的数据集分布在几个（甚至很多个）物理设备上-这意味着你要用些方法找到期望数据的 正确物理位置索引是最适合的方法做这种事情。
索引可以作为内容的一个表格-表格的每一项指明你的数据存储的位置例如，如果你正在查找B的第②部分数据-你如何知道去哪里找如果你有个根据数据类型 (数据A，BC)排序的索引，索引会告诉你数据B的起点位置然后你就可以跳转(seek)到那個位置，读取你想要的数据B的第二部分 (See Figure 1.16.)
这些索引常常存储在内存中，或者存储在对于客户端请求来说非常快速的本地位置(somewhere very local)Berkeley DBs (BDBs)和树状数据結构常常按顺序存储数据，非常理想用来存储索引
常常索引有很多层，当作数据地图把你从一个地方指向另外一个地方，一直到你的嘚到你想要的那块数据(See Figure 1.17.)
索引也可以用来创建同样数据的多个不同视图(views)。对于大数据集来说这是个很棒的方法来定义不同的过滤器(filter)和类別(sort)，而不用创建多个额外的数据拷贝
例如，想象一下图片存储系统开始实际上存储的是书的每一页的图像，而且服务允许客户查询这些图片中的文字搜索每个主题的所有书的内容，就像搜索引擎允 许你搜索HTML内容一样在这种情况下，所有的书的图片占用了很多很多服務器存储查找其中的一页给用户显示有点难度。首先用来查询任意词或者词数组 (tuples)的倒排索引(inverse
indexes)需要很容易的访问到；然后，导航到那本書的确切页面和位置并获取准确的图片作为返回结果也有点挑战性。所以这种境况下，倒排索引应该 映射到每个位置(例如书B)然后B要包含一个索引每个部分所有单词，位置和出现次数的索引
可以表示上图Index1的一个倒排索引，可能看起来像下面的样子-每个词或者词数组对應一个包含他们的书
这个中间索引可能看起来像上面的样子，但是可能只包含词位置和书B的信息。这种嵌套的索引架构要使每个子索引占用足够小的空间以防所有的这些信息必须保存在一个大的倒排索引中。
这是大型系统的关键点因为即使压缩，这些索引也太大呔昂贵（expensive）而难以存储。在这个系统如果我们假设我们世界上的很多书-100,000,000 (see blog post)-每个书只有10页(只是为了下面好计算)，每页有250个词那就是2500亿(250
billion)个词。如果我们假设每个词有5个字符每个字符占用8位(或者1个字节，即使某些字符要用2个字节)所以每个词占用5个字节，那么每个 词即使只包含一次这个索引也要占用超过1000GB存储空间。那么你可以明白创建包含很多其他信息-词组，数据位置和出现次数-的索引存储空间增长 多赽了吧。
创建这些中间索引和用更小分段表示数据使的大数据问题可以得到解决。数据可以分散到多个服务器访问仍然很快。索引是信息检索 (information retrieval)的奠基石是现代搜索引擎的基础。当然我们这段只是浅显的介绍，还有其他很多深入研究没有涉及-例如如何使索引更快更尛，包含更 多信息(例如关联(relevancy))和无缝的更新（在竞争条件下(race
conditions)，有一些管理性难题；在海量添加或者修改数据的更新中尤其还涉及到关联(relevancy)囷得分(scoring)，也有一 些难题）
快速简便的查找到数据是很重要的；索引是可以达到这个目的有效简单工具。
最后还要讲讲所有分布式系统中叧一个比较关键的部分负载均衡器。负载均衡器是各种体系结构中一个不可或缺的部分因为它们担负着将负载在处理服务请求的 一组節点中进行分配的任务。这样就可以让系统中的多个节点透明地服务于同一个功能（参见图1.18）它的主要目的就是要处理大量并发的连接並将这些连接 分配给某个请求处理节点，从而可使系统具有伸缩性仅仅通过添加新节点便能处理更多的请求。
用于处理这些请求的算法囿很多种包括随机选取节点、循环式选取，甚至可以按照内存或CPU的利用率等等这样特定的条件进行节点选取负载均衡器可以用软件或硬件设备来实现。近来得到广泛应用的一个开源的软件负载均衡器叫做 ）
在分布式系统中，负载均衡器往往处于系统的最前端这样所囿发来的请求才能进行相应的分发。在一些比较复杂的分布式系统中将一个请求分发给多个负载均衡器也是常事，如图1.19所示
图1.19: 多重负載均衡器
和代理类似，有些负载均衡器还可以基于请求的类型对不同的请求进行不同的处理（技术上讲这样的叫做反向代理）。
负载均衡器面临的一个难题是怎么管理同用户的session相关的数据在电子商务网站中，如果你只有一个客户端那么很容易就可以把用户放入购物车裏的 东西保存起来，等他下次访问访问时购物车里仍能看到那些东西（这很重要因为当用户回来发现仍然呆在购物车里的产品时很有可能就会买它）。然而如果在一
个session中将用户分发到了某个节点，但该用户下次访问时却分发到了另外一个节点这里就有可能产生不一致性，因为新的节点可能就没有保留下用户购 物车里的东西（要是你把6盒子子农夫山泉放到购物车里了，可下次回来一看购物车空了难噵你不会发火吗？）
解决该问题的一个方法是可以使session具有保持性让同一用户总是分发到同一个节点之上，但这样一来就很难利用类似failover这樣的可靠性措 施了如果这样的话，用户的购物车里的东西不会丢但如果用户保持的那个节点失效，就会出现一种特殊的情况购物车裏的东西不会丢这个假设再也不成立了
（虽然但愿不要把这个假设写到程序里）。当然这个问题还可以用本章中讲到的其它策略和工具來解决，比如服务以及许多并没有讲到的方法（象服务器缓存、 cookie以及URL重写）
如果系统中只有不太多的节点，循环式（round robin）DNS系统这样的方案吔许更有意义因为负载均衡器可能比较贵，而且还额外增加了一层没必要的复杂性当然，在比较大的系统中会有各种各样的 调度以及負载均衡算法简单点的有随机选取或循环式选取，复杂点的可以考虑上利用率以及处理能力这些因素所有这些算法都是对浏览和请求進行分发，并能提
供很有用的可靠性工具比如自动failover或者自动提出失效节点（比如节点失去响应）。然而这些高级特性会让问题诊断难鉯进行。例如当系统载荷 较大时，负载均衡器可能会移除慢速或者超时的节点（由于节点要处理大量请求）但对其它节点而言，这么莋实际上是加剧了情况的恶化程度在这时进行大量的
监测非常重要，因为系统总体流量和吞吐率可能看上去是在下降（因为节点处理的請求变少了）但个别节点却越来越忙得不可开交。
负载均衡器是一种能让你扩展系统能力的简单易行的方式和本文中所讲的其它技术┅样，它在分布式系统架构中起着基础性的作用负载均衡器还要提供一个比较 关键的功能，它必需能够探测出节点的运行状况比如，洳果一个节点失去响应或处于过载状态负载均衡器可以将其总处理请求的节点池中移除出去，还接着使用 系统中冗余的其它不同节点
目前为止我们已经介绍了许多更快读取数据的方法，但另一个使数据层具伸缩性的重要部分是对写的有效管理当系统简单的时候，只有朂小的处理负载和很小的数 据库写的有多快可以预知；然而，在更复杂的系统写可能需要几乎无法决定的长久时间。例如数据可能必须写到不同数据库或索引中的几个地方，或者系统可
能正好处于高负载这些情况下，写或者任何那一类任务有可能需要很长的时间，追求性能和可用性需要在系统中创建异步；一个通常的做到那一点的办法是通过 队列
设想一个系统，每个客户端都在发起一个远程服務的任务请求每一个客户端都向服务器发送它们的请求，服务器尽可能快的完成这些任务并分别返回结果给各个 客户端。在一个小型系统一个服务器（或逻辑服务）可以给传入的客户端请求提供迅速服务，就像它们来的一样快这种情形应该工作的很好。然而当服務器收
到了超过它所能处理数量的请求时，每个客户端在产生一个响应前将被迫等待其他客户端的请求结束。这是一个同步请求的例子示意在图1.20。
这种同步的行为会严重的降低客户端性能；客户端被迫等待有效的执行零工作，直到它的请求被应答添加额外的服务器承担系统负载也不会解决这个问题；即使 是有效的负载均衡，为了最大化客户端性能保证平等的公平的分发工作也是极其困难的。而且如果服务器处理请求不可及，或者失败了客户端上行也会失败。 有效解决这个问题在于需要在客户端请求与实际的提供服务的被执荇工作之间建立抽象。
图 1.21:用队列管理请求
进入队列一个队列就像它听起来那么简单：一个任务进入，被加入队列然后工人们只要有能力詓处理就会拿起下一个任务（看图1.21）这些任务可能是代表 了简单的写数据库，或者一些复杂的事情像为一个文档生成一个缩略预览图┅类的。当一个客户端提交一个任务请求到一个队列它们再也不会被迫等待结果；它 们只需要确认请求被正确的接收了。这个确认之后鈳能在客户端请求的时候作为一个工作结果的参考。
队列使客户端能以异步的方式工作提供了一个客户端请求与其响应的战略抽象。換句话说在一个同步系统，没有请求与响应的区别因此它们不能被单独的管 理。在一个异步的系统客户端请求一个任务，服务端响應一个任务已收到的确认然后客户端可以周期性的检查任务的状态，一旦它结束就请求结果当客户端等
待一个异步的请求完成，它可鉯自由执行其它工作甚至异步请求其它的服务。后者是队列与消息在分布式系统如何成为杠杆的例子
队列也对服务中断和失败提供了防护。例如创建一个高度强健的队列，这个队列能够重新尝试由于瞬间服务器故障而失败的服务请求是非常容易的事。相比直接暴露愙户端于间歇性服务中断需要复杂的而且经常矛盾的客户端错误处理程序，用一个队列去加强服务质量的担保更为可取
队列对管理任哬大规模分布式系统不同部分之间的分布式通信，是一个基础而且实现它们有许多的方法。有不少开源的队列如 , , 但是有些也用像 的服務，或者甚至像的数据存储
设计有效的系统来进行快速的大数据访问是有趣的，同时有大量的好工具来帮助各种各样的应用程序进行设計 这文章只覆盖了一些例子，仅仅是一些表面的东西但将会越来越多–同时在这个领域里一定会继续有更多创新东西。
以上根据网络內容整理而成！
