绝对不要信任单点故障

摘要：绝对不要实现且一定要减少单点数障。在架构图上我出单点实例。尽量采用主动/主动配置。通过多个实景大化可用性。尽量采用主动/主动配置，不要用主动被动解决方案。利用均衡器均衡跨服务实例的流量。对于单例模式，使用主动/被动配置的控制。 绝对不要实现且一定要减少单点数障。在架构图上我出单点实例。尽量采用主动/主动配置。通过多个实景大化可用性。尽量采用主动/主动配置，不要用主动被动解决方案。利用均衡器均衡跨服务实例的流量。对于单例模式，使用主动/被动配置的控制。

在数学中，单元素集合是只有一个元素的集合，如{A}。在程序设计中，单例模式指的是一种设计模式，它模仿了数学概念，限制了一个类只能实例化一个对象。这种设计模式对协调资源非常有用，但程序员常为了省事而过度使用它，这个话题我们之后再讨论。在系统架构中，单例模式，或者更恰当地说是单例反模式，被称为单点故障(SPOF)也就是说，当系统中的某个组件只有一个实例时，一旦该实例出故障，就会造成系统范围的影响。



SPOF在系统中随处可见，从单个的Web服务器到单个的网络设备，但系统中最常见的SPOF是数据库。其原因在于数据库是最难扩展到多个节点上的，因此它只有一个实例。在图9-1中，即使登录、搜索和结账服务器都有冗余，数据库仍是SPOF。更精的是，所有服务池都依赖于这一个数据库。虽然任何SPOF都不好，但数据库SPOF的问题更大，如果数据库速度下降或者期读了，那么对数据库进行同步调用的所有服务池都将受到这一事件影响。

我们常说给客户的一句口头禅是“一切都会出故障”。这句话适用于服务器、存储系统、网络设备和数据中心。只要你知道的，都会出故障。

虽然很多人认为数据中心是不会出故障的，但多年来，我们自己经历了十几次数据中心运行中断。高可用的存储区域网络也是如此，虽然它们比旧的SCSI硬盘阵列可靠得多，但仍旧会出故障。

大多数解决SPOF的方法是申请另一台硬件，如X轴扩展所示的通过克隆服务，让每种服务都有两个或更多个实例在运行。遗憾的是，事实并非总是如此简单。让我们回头再看看编写单例模式的步骤。虽然不是所有的单例类都不允许在多台服务器上运行一个服务，但有些实现绝对会让你免于遭受可怕的后果。较简单的情况是，如果代码中有一个类，用于从用户账户中减去基金，用单例模式实现它就会让用户的余额免于不测，如成为负数。如果把这段代码放在两台独立的服务器上，没有额外的控制措施或联络信号，则很可能会造成两个事务同时在用户账户中记人借额，从而导致错误或不想发生的状况。对于这种情况，我们需要修复代码，或者依赖外部控制来预防。但最令人满满意的解决方案是修复代码，在多个主机上实现服务，通常我们需要快速修复SPOF。作为本原则的最后一个要点，我们接下来将讨论几个快速修复方法。

第一个方法最简单，是使用主动/被动配置。一个服务在一台服务器上主动运行，在另外一台服务器上被动运行(不接收流量)。这种热/冷配置，常被用作删除数据库SPOF的第一步。接下来的方法是用系统中的另一个组件控制数据访问。如果SPOF是服务，那么用数据库锁可以控制数据的访问。如果SPOF是数据库，那么可以设置主一从配置，由应用控制数据访问，写更新操作由主数据库完成，读选择操作由从数据库完成。最后一个用于修复SPOF的配置是负载均衡器。如果Web服务器或应用服务器的一个服务是SPOF，且在代码中不能消除，那么可以利用负载均衡器把一个用户的请求只发送给池中的一台服务器。这是通过会话cookie实现的，即设置用户的浏览器，且允许负载均衡器每次都把该用户的请求重定向到同一个Web或应用服务器，从而形成一种一致状态。

我们介绍了几种消除SPOF的方法，在不能及时修改代码的情况下可以轻松地实现它们。但是最后的方法最好，即修复代码，允许网站设计服务的多个实例在不同的物理服务器上运行，从而尽可能消除SPOF。记住，“一切都会出故障”，所以当SPOF出故障时，请不要吃惊。