分区我们可能遇见单一服务器无法存放的庞大数据集。也可能遇到一个需要过多计算资源的操作，导致性能下降，急需增添容量。这些情况下，你都有两种选择：横向或纵向扩展。纵向扩展意味着对单一服务器增添更多资源。对于一个非常庞大的数据集，这可能意味着为单一服务器增加更多（或更大）的硬盘以存放整个数据集。而对于计算操作，这可能意味着将操作移到一个拥有更快的 CPU 或 更大的内存的服务器中。无论哪种情况，纵向扩展都是为了使单个服务器能够自己处理更多的方法。另一方面，对于横向扩展，则是增加更多的节点。例如庞大的数据集，你可以用第二个服务器来存放部分数据；而对于计算操作，你可以切割计算，或是通过额外的节点加载。想要充分的利用横向扩展的优势，你应该以内在的系统构架设计原则来实现，否则的话，实现的方法将会变成繁琐的修改和切分操作。说道横向分区，更常见的技术是将你的服务分区，或分片。分区可以通过对每个功能逻辑集的分割分配而来;可以通过地域划分，也可以通过类似付费 vs. 未付费用户来区分。这种方式的优势是可以通过增添容量来运行服务或实现数据存储。以我们的图像服务器为例，将曾经储存在单一的文件服务器的图片重新保存到多个文件服务器中是可以实现的，每个文件服务器都有自己惟一的图片集。（见图表1.4。）这种构架允许系统将图片保存到某个文件服务器中，在服务器都即将存满时，像增加硬盘一样增加额外的服务器。这种设计需要一种能够将文件名和存放服务器绑定的命名规则。一个图像的名称可能是映射全部服务器的完整散列方案的形式。或者可选的，每个图像都被分配给一个递增的 ID，当用户请求图像时，图像检索服务只需要保存映射到每个服务器的 ID 范围（类似索引）就可以了。图 1.4: 使用冗余和分区实现的图片存储服务
当然，为多个服务器分配数据或功能是充满挑战的。一个关键的问题就是数据局部性；对于分布式系统，计算或操作的数据越相近，系统的性能越佳。因此，一个潜在的问题就是数据的存放遍布多个服务器，当需要一个数据时，它们并不在一起，迫使服务器不得不为从网络中获取数据而付出昂贵的性能代价。另一个潜在的问题是不一致性。当多个不同的服务读取和写入同一共享资源时，有可能会遭遇竞争状态——某些数据应当被更新，但读取操作恰好发生在更新之前——这种情形下，数据就是不一致的。例如图像托管方案中可能出现的竞争状态，一个客户端发送请求，将其某标题为“狗”的图像改名为”小家伙“。而同时另一个客户端发送读取此图像的请求。第二个客户端中显示的标题是“狗”还是“小家伙”是不能明确的。当然，对于分区还有一些障碍存在，但分区允许将问题——数据、负载、使用模式等——切割成可以管理的数据块。这将极大的提高可扩展性和可管理性，但并非没有风险。有很多可以降低风险，处理故障的方法；不过篇幅有限，不再赘述。若有兴趣，可见于此文，获取更多容错和检测的信息。1.3. 构建高效和可伸缩的数据访问模块在设计分布式系统时一些核心问题已经考虑到，现在让我们来讨论下比较困难的一部分：可伸缩的数据访问。对于大多数简单的web应用程序，比如LAMP系统，类似于图 Figure 1.5.Figure 1.5: 简单web应用程序
随着它们的成长，主要发生了两方面的变化：应用服务器和数据库的扩展。在一个高度可伸缩的应用程序中，应用服务器通常最小化并且一般是 shared-nothing架构（译注：shared nothing architecture是一 种分布式计算架构，这种架构中不存在集中存储的状态，整个系统中没有资源竞争，这种架构具有非常强的扩张性，在web应用中广泛使用）方式的体现，这使得系统的应用服务器层水平可伸缩。由于这种设计，数据库服务器可以支持更多的负载和服务；在这一层真正的扩展和性能改变开始发挥作用了。剩下的章节主要集中于通过一些更常用的策略和方法提供快速的数据访问来使这些类型服务变得更加迅捷。Figure 1.6: Oversimplified web application
大多数系统简化为如图 Figure 1.6所示，这是一个良好的开始。如果你有大量的数据，你想快捷的访问，就像一堆糖果摆放在你办公室抽屉的最上方。虽然过于简化，前面的声明暗示了两个困难的问题：存储的可伸缩性和数据的快速访问。为了这一节内容，我们假设你有很大的数据存储空间（TB），并且你想让用户随机访问一小部分数据（查看Figure 1.7）。这类似于在图像应用的例子里在文件服务器定位一个图片文件。Figure 1.7: Accessing specific data
这非常具有挑战性，因为它需要把数TB的数据加载到内存中；并且直接转化为磁盘的IO。要知道从磁盘读取比从内存读取慢很多倍-内存的访问速度如同敏捷的查克·诺里斯（译注：空手道冠军），而磁盘的访问速度就像笨重的卡车一样。这个速度差异在大数据集上会增加更多；在实数顺序读取上内存访问速度至少是磁盘的6倍，随机读取速度比磁盘快100,000倍（参考“大数据之殇”http://queue.acm.org/detail.cfm?id=1563874）。另外，即使使用唯一的ID，解决获取少量数据存放位置的问题也是个艰巨的任务。这就如同不用眼睛看在你的糖果存放点取出最后一块Jolly Rancher口味的糖果一样。谢天谢地，有很多方式你可以让这样的操作更简单些；其中四个比较重要的是缓存，代理，索引和负载均衡。本章的剩余部分将讨论下如何使用每一个概念来使数据访问加快。缓存缓存利用局部访问原则：最近请求的数据可能会再次被请求。它们几乎被用于计算机的每一层：硬件，操作系统，web浏览器，web应用程序等等。缓存就像短期存储的内存：它有空间的限制，但是通常访问速度比源数据源快并且包含了大多数最近访问的条目。缓存可以在架构的各个层级存在，但是常常在前端比较常见，在这里通常需要在没有下游层级的负担下快速返回数据。在我们的API例子中如何使用缓存来快速访问数据？在这种情况下，有两个地方你可以插入缓存。一个操作是在你的请求层节点添加一个缓存，如图 Figure 1.8.Figure 1.8: Inserting a cache on your request layer node
直接在一个请求层节点配置一个缓存可以在本地存储相应数据。每次发送一个请求到服务，如果数据存在节点会快速的返回本地缓存的数据。如果数据不在缓存中，请求节点将在磁盘查找数据。请求层节点缓存可以存放在内存和节点本地磁盘中（比网络存储快些）。Figure 1.9: Multiple caches
当你扩展这些节点后会发生什么呢？如图Figure 1.9所示，如果请求层扩展为多个节点，每个主机仍然可能有自己的缓存。然而，如果你的负载均衡器随机分配请求到节点，同样的请求将指向不同的节点，从而增加了缓存的命中缺失率。有两种选择可以解决这个问题：全局缓存和分布式缓存。
