分析高可用性系统的硬件和软件设计模式

在20世纪70年代，N版编程(N-version programming)是先进的软件容错设计方法。此后，这种设计模式引发了一系列问题：随着该技术的采用，软件开发成本直线飙升，因为必须成立N个单独的团队开发N套相互独立的软件。如果期望降低成本，则将陷入所谓的“平均智商( Average IQ)”怪圈：较低成本的开发团队意味着较低质量的软件工程师，而这些工程师只能开发出较低质量的代码。因此，最终只能得到充斥着以N种不同方式产生故障的N种不同程序。

N版编程面临的另一个问题在于如何为N个独立开发团队提供输入。一般情况下，将为所有的N个开发团队提供相同的规范标准。然而，一旦规范存在缺陷，那么将得到N个独立开发的包含类似软件故障的版本。如果系统发布之后，规范或使用错误得到识别，那么每个新错误都需要纠正N次，即N个不同的实现都需要加以纠正，这样维护成本就相当惊人。现在，最佳的N版编程方法是让第一流的软件开发团队，利用最可靠的底层架构、软件开发工具、技术和测试来开发出高质量的软件版本。

校验点恢复

与基于静态冗余的N版编程不同，许多软件容错设计模式均基于动态冗余。这些设计模式均包含以下四个步骤：

1. 故障检测

2. 损害评估与 限制(有时也称为“防火墙处理”)

3. 故障恢复

4. 故障处理和业务继续

步骤二中，当检测到软件错误时，一般可以采用失效保护。但软件往往极其复杂，因此消除故障软件导致的后果也并非轻而易举。事务的概念是解决该问题的一个有效工具，事务是应用状态下操作的集合，这样事务的起始点和结束点均是应用的稳定状态。例如，每个城市的市政厅都具有一个包含该城市所有居民信息的文件系统。当一对夫妻结婚时，他们的姓名和结婚日期都记录在一个命名为“已婚夫妻”的文件中。另外，记载新郎从单身到已婚状态变化的文件称为“男性居民”；记载新娘从单身到已婚状态变化的文件称为“女性居民”。如果上述3个文件中的一个未能得到有效更新或者软件在更新过程中突然崩溃，我们将不得不返回到该婚姻“事务”的起始点。否则，将只会以不稳定状态而告终，如新郎显示为已婚状态，而新娘则仍然显示为单身状态。稳定状态只出现在婚姻事务的起始点以及得到成功处理的结束点。

如果希望在容错中引入事务概念，系统必须能在事务的起始点保存系统状态，这称为检验指示。检验指示需要在开始新事务之前迅速保存系统状态，并且必须要求先前的事务以无差错状态结束。这里，一种基本的恢复策略是再执行方法：一旦事务中检测到错误，事务将进行失效保护，系统将重新载入最近保存的检验点。这样业务又能从检验点继续执行下去，并允许在该稳定状态上进行新的事务处理。然而，这样将丢失进行失效保护的事务。这类故障恢复也称为后向故障恢复，因为软件状态将还原到先前的一个无差错点上。

简单的检验指示本身也容易引发单点失效，因为在保存检验点状态时有可能出现故障，但我们可以采用一种称为检验点还原(checkpoint-rollback)的方法解决这个问题，如图2所示。图中，椭圆符号代表通过发送队列消息进行通信的软件客户和软件服务器。一个事务可以包含许多从客户机发往服务器的请求消息以及从服务器发往客户机的响应消息。在一个事务中，数据在服务器中修改。在事务的结束点，右图所示的两个恒定大容量存储设备将记录稳定的数据集和事务序列号。如果某一时刻检测到错误，而服务器已被关闭，那么服务器将重启(或启动备用服务器)。作为启动恢复过程的一部分，两个大容量存储设备还需要检验事务序列号。服务器数据将根据包含最高序列号的设备进行恢复。因为故障出现在设备检验中，因此另一大容量设备将带有较低的序列号。

流程对设计模式

检验点设计模式的一个缺陷在于故障恢复时间过长。启动或重启服务器需要进行许多处理，才能恢复到检验点状态。“热备用”服务器与其自带的恒定大容量存储设备的直接协同工作可以加速恢复，该设计模式也称为流程对(process pair)设计，如图3所示。

图3中，方框图中央是一个工作原理与先前检验点情形非常相似的主服务器，客户机直接与主服务器协同工作。一旦主服务器成功地完成整个事务，将传送与新的稳定状态相关的信息至备用服务器(右端的服务器)。主服务器和备用服务器都将在恒定大容量设备中记录数据。这样，备用服务器就能保存完整事务的当前信息。当主服务器准备就绪并可供客户机使用，将向备用服务器发送常规的“心跳消息(heartbeat message)”，这些心跳消息还可以同某些检验点消息相结合。一旦检测到心跳消息流终