![](https://csdnimg.cn/release/download_crawler_static/6874489/bg5.jpg)
当然,如果你有两个不同的端点,上面的例子可能会运行的很好(事实上,这非常类似于几
个云存储供应商之间的实现和内容分发网络)。虽然有很多种方法可以解决这些瓶颈,但每
个人都会有不同的权衡,所以采用适合你的方法才是最重要的。
例如,Flickr 解决这个读/写问题是通过分发用户跨越不同的碎片,每个碎片只能处理一组用
户,但是随着用户数的增加,更多的碎片也会相应的添加到群集里(请参阅 Flickr 的扩展介
绍)。在第一个例子中,它更容易基于硬件的实际用量进行扩展(在整个系统中的读/写数
量),而 Flickr 是基于其用户群进行扩展(but forces the assumption of equal usage across
users so there can be extra capacity)。而前面的那个例子,任何一个中断或者问题都会降
低整个系统功能(例如任何人都没办法执行写操作),而 Flickr 的一个中断只会影响到其所
在碎片的用户数。在第一个例子中,它更容易通过整个数据集进行操作——例如,更新写服
务,包括新的元数据或者通过所有的图片元数据进行搜索——而 Flickr 架构的每个碎片都需
要被更新或搜索(或者需要创建一个搜索服务来收集元数据——事实上,他们就是这样做的)。
当谈到这些系统时,其实并没有非常正确的答案,但有助于我们回到文章开始处的原则上看
问题。确定系统需求(大量的读或写或者两个都进行、级别并发、跨数据查询、范围、种类
等等),选择不同的基准、理解系统是如何出错的并且对以后的故障发生情况做些扎实的计
划。
冗余
为了可以正确处理错误,一个 Web 架构的服务和数据必须具备适当的冗余。例如,如果只
有一个副本文件存储在这台单独的服务器上,那么如果这台服务器出现问题或丢失,那么该
文件也随即一起丢失。丢失数据并不是什么好事情,避免数据丢失的常用方法就是多创建几
个文件或副本或冗余。
同样也适用于服务器。如果一个应用程序有个核心功能,应确保有多个副本或版本在同时运
行,这样可以避免单节点失败。
在系统中创建冗余,当系统发生危机时,如果需要,可以消除单点故障并提供备份或备用功
能。例如,这里有两个相同的服务示例在生产环境中运行,如果其中一个发生故障或者降低,
那么该系统容错转移至那个健康的副本上。容错转移可以自动发生也可以手动干预。
服务冗余的另一重要组成部分是创建一个无共享架构。在这种体系结构中,每个节点都能相
互独立运行,并且没有所谓的中央“大脑”管理状态或协调活动其他节点。这对系统的可扩展
帮助很大,因为新节点在没有特殊要求或知识的前提下被添加。然而,最重要的是,这些系
统是没有单点故障的,所以失败的弹性就更大。