正文
对于这种瓶颈，一个好的规划案例是将读取和写入图片分离为两个独立的服务，如图Figure 1.2.所示。这让我们可以单独的扩展其中任意一个（因为有可能我们读操作比写操作要频繁很多），同时也有助于我们理清每个节点在做什么。最后，这也避免了未来的忧虑，这使得故障诊断和查找问题更简单，像慢读问题。
这种方法的优点是我们能够单独的解决各个模块的问题-我们不用担心写入和检索新图片在同一个上下文环境中。这两种服务仍然使用全球资料库的图片，但是它们可通过适当的服务接口自由优化它们自己的性能（比如，请求队列，或者缓存热点图片-在这之上的优化）。从维护和成本角度来看，每个服务按需进行独立规模的规划，这点非常有用，试想如果它们都组合混杂在一起，其中一个无意间影响到了性能，另外的也会受影响。
当然，上面的例子在你使用两个不同端点时可以很好的工作（事实上，这非常类似于云存储和内容分发网络）。虽然有很多方式来解决这样的瓶颈，但每个都有各自的取舍。
比如，Flickr通过分配用户访问不同的分片解决这类读/写问题，每一个分片只可以处理一定数量的用户，随着用户的增加更多的分片被添加到集群上。在第一个例子中，可以根据实际用途更简单的规划硬件资源（在整个系统中读和写的比例），然而，Flickr规划是根据用户基数（假定每个用户拥有相同的资源空间）。在前者中一个故障或者问题会导致整个系统功能的下降（比如，全部不能写入文件了），然而Flickr一个分片的故障只会影响到相关的那部分用户。在第一个例子中，更容易操作整个数据集-比如，在所有的图像元数据上更新写入服务用来包含新的元数据或者检索-然而在Flickr架构上每一个分片都需要执行更新或者检索（或者需要创建个索引服务来核对元数据-找出哪一个才是实际结果）。
冗余(Redundancy)
为了优雅的处理故障，web架构必须冗余它的服务和数据。例如，单服务器只拥有单文件的话，文件丢失就意味这永远丢失了。丢失数据是个很糟糕的事情，常见的方法是创建多个或者冗余备份。
同样的原则也适用于服务。如果应用有一个核心功能，确保它同时运行多个备份或者版本可以安全的应对单点故障。
在系统中创建冗余可以消除单点故障，可以在紧急时刻提供备用功能。例如，如果在一个产品中同时运行服务的两个实例，当其中一个发生故障或者降级(degrade)，系统可以转移(failover)到好的那个备份上。故障转移(Failover)可以自动执行或者人工手动干预。
服务冗余的另一个关键部分是创建无共享(shared-nothing)架构。采用这种架构，每个接点都可以独立的运作，没有中心”大脑”管理状态或者协调活动。这可以大大提高可伸缩性(scalability)因为新的接点可以随时加入而不需要特殊的条件或者知识。而且更重要的是，系统没有单点故障。所以可以更好的应对故障。
例如，在我们的图片服务应用，所有的图片应该都冗余备份在另外的一个硬件上（理想的情况下，在不同的地理位置，以防数据中心发生大灾难，例如地震，火灾），而且访问图片的服务（见Figure 1.3.）-包括所有潜在的服务请求-也应该冗余。（负载均衡器是个很好的方法冗余服务，但是下面的方法不仅仅是负载均衡）
Figure 1.3: 使用冗余的图片存储
分区
我们可能遇见单一服务器无法存放的庞大数据集。也可能遇到一个需要过多计算资源的操作，导致性能下降，急需增添容量。这些情况下，你都有两种选择：横向或纵向扩展。
纵向扩展意味着对单一服务器增添更多资源。对于一个非常庞大的数据集，这可能意味着为单一服务器增加更多（或更大）的硬盘以存放整个数据集。而对于计算操作，这可能意味着将操作移到一个拥有更快的 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所示，这是一个良好的开始。如果你有大量的数据，你想快捷的访问，就像一堆糖果摆放在你办公室抽屉的最上方。虽然过于简化，前面的声明暗示了两个困难的问题：存储的可伸缩性和数据的快速访问。
