分布式集群运行的容错软件设计

Question

关键任务软件系统(例如航天器上的系统-控制软件)通常采用不同团队开发的多个冗余软件模块(有时使用不同的编程语言)，以达到相同的接口和行为规范。这个想法是，只有在某些极端的角落案例中才出现的软件错误，在生产前的测试中没有被发现，应该只在其中一个模块中进行实现，而其他模块不受影响，因为它们是由不同的团队使用不同的工具/语言开发的。

然而，这些相对较小的(任务-)关键系统--整体故障--可能会产生重大的财务影响，确实是容错的，似乎使用了用同一种语言编写的软件的冗余实例，也许是由同一组开发人员编写的，这不仅确保了高可用性，而且对正在进行的事务也具有容错能力，例如，在为请求服务的节点上的故障可以在另一个节点上无缝地继续。在硬件故障的情况下，我可以理解为什么这可以工作。然而，在软件故障的情况下，为什么/如何工作呢？是不是导致第一个节点失败的同一个软件故障也会影响另一个节点呢？

另外，是否有一些设计模式允许使用本质上不容错的组件组成容错系统？

Answer 1

如果故障在硬件如中央处理器中，或者在非ECC存储器模块中，那么使用相同代码但使用不同硬件的多个节点确实会有所帮助。

但是，如果故障在代码中且与硬件无关，那么如果所有节点共享相同的代码，那么它将在每个节点上显示出来。

在这里，你有三个选择：

• 首先编写更好的软件。进行代码评审，增加测试覆盖率。这是大多数公司使用的技术，用于那些不需要生命的项目，但仍然被认为是可靠的。
• 使用形式证明。这种方法部分用于一些生命关键项目，成本太高，无法合理地用于普通软件产品。
• 让两个团队使用不同的编程语言和不同的平台独立编写相同的软件。这正是你在问题中所说的，可能是另外两种方法之间的一个很好的折衷。

Answer 2

容错系统的软件方面在于环境。虽然运行两个相同的系统会看到相同的软件错误被复制，但通常情况下，一个系统会陷入错误状态(例如线程锁定问题、内存不足等)，将处理移到辅助服务器上将不会有相同的环境，并将继续正确运行(或至少在第一个系统被修复/重新启动之前)。

Bugs可分为两大类--它们在正常操作中显示自己，并且易于复制(例如您单击菜单项，由于编码失败而弹出一个错误对话框)。但是另一种类型的错误几乎是随机出现的，因为软件是如此复杂，并且依赖于其他因素。线程是一个最好的例子:一个程序可以完美运行数年，直到有一天它突然挂起。调查这个bug可能会显示出一个死锁，直到它显现出来之前，没有人考虑过它。

这些是很难检测到的错误，也是创建容错系统的原因。您可以重新启动系统并清除故障，但是重新启动需要时间并导致停机。如果您有一个冗余系统准备接管，您可以重新启动，而不需要任何停机时间。您知道，大多数系统会在很长一段时间内正常工作，直到某些事情发生为止。即使有错误的系统也会正确运行。