基本的冗余架构分为两种，一种是主动式冗余，另一种就是被动式冗余。

长时间以来，由于软件的固有特性：不会磨损、错误如果不被发现就永远存在、相同的版本在相同的条件下错误也是相同的。促使人们认为软件的冗余是没有意义的。但随着软件系统的复杂性增大、分布式应用的广泛部署，使软件赖以运行的环境越来越复杂，运行环境的可靠性必须通过冗余实现。这样就使得，虽然软件本身冗余没有意义，但要在冗余的硬件及操作系统中运行，软件也必须支持冗余功能。分布式软件的冗余特性就这样被重视起来。

在关键控制系统中，比如卫星控制系统、飞机及机场控制系统、铁路控制系统等，对系统的可靠性有苛刻地要求。在这些系统中，所有组件都要求有冗余设计，包括任何硬件及软件环节，要求任何单点故障不影响系统正常运行，即使是关键节点故障，系统中其他部分也要求具备基本的应急功能。

在系统中，抽象层次越高的节点，其支持更多的接口，包含更多的信息和处理逻辑，所以复杂度也越高。同时，复杂度越高的节点，支持冗余的难度越大。这就是硬件节点容易冗余，而软件节点不容易冗余的原因。

对冗余节点的最基本的要求是，在主节点发生故障时，备用节点自动接管主节点，完成所有的功能及提供的所有的服务。对冗余的更进一步的要求是，在主备节点切换的过程中，不允许有信息的丢失，切换过程中的发生的任何事件都不允许丢失。

对冗余功能的性能要求分两个方面，一个是主节点故障允许时间T1，也就是在主节点不能正常响应的多长时间后，才认为是主节点失败，进入主备节点切换程序；另一个是备节点接管的时间T2，也就是备节点在决定要接管责任后，需要多长时间才能进入正常的操作状态。这样系统对该节点的故障允许时间T就是T1和T2之和。一般大型的控制系统中，在跟操作员直接相关的软件节点层次，故障允许时间一般在秒级，比如在笔者参与的一个地铁控制系统中，该时间要求是2秒。

被动式冗余主要由服务的请求者实现，基于失败重试原理，在可用的服务提供者之间重试，直到找到一个可用的提供者。被动式冗余是简单的，但也有很大的局限性，它要求冗余节点只是作为信息的处理者，完全作为C/S架构中的S，而不可能作为信息的发起者。这类冗余在事务处理系统（MIS）中比较常见，因为这类系统总是响应用户的操作，而很少会有自动收集信息并处理的业务。

在控制系统中的冗余架构，基本都是主动式冗余架构。它要求冗余节点能够自动检查主备节点的运行状态，并且在主节点失败时自动切换到备节点。

主动冗余架构也有两种实现方式，一是主备节点间设有交换运行状态的通讯通道，由他们自行协商何时进行主备切换，可以称为自控方式。另一种是基于一个中心的冗余控制器，冗余控制器分别与主备节点通讯，并决定何时进行主备切换，可以称为集控方式。

在笔者参与的地铁控制系统中，两个与硬件直接通讯的主备RTU(REMOTE TERMINAL UNIT)之间就采用自控方式。当两个RTU之间不能通讯时，或者当前系统中仅有一个RTU时，它们会将自己设定为主节点，提供所有服务。当两个RTU建立了通讯连接后，它们会就谁是主节点进行协商，主节点条件包括，是否连接有更多的外围设备，是否正在对外围系统提供服务等等。当确定谁是主节点后，两个RTU就会自觉把自己设定为相应的工作状态。自动方式中的主备节点，要求它们在系统中具有不同的逻辑地址，以让它们的客户端能够分别找到它们，并且确定它们的工作状态，并对它们提供的信息进行不同的处理。

在集控方式的实现中，主备节点在运行时都向冗余控制器注册，由冗余控制器确定他们的运行方式，另外冗余控制器还担任监视主备节点运行状态的责任。当主节点在设定的时间内没有响应时，冗余控制器则重新设定主备节点的运行方式，备节点代替主节点处理内部信息、响应请求。在这种情况下，主备节点具有使用相同的逻辑地址，它们的运行状态对客户程序是透明的，所有的客户请求都通过冗余控制器转发给主节点。

在基于构件的软件架构中，比如J2EE, CORBA, .NET, WEBSERVISE等，任一软件构件都具有唯一的构件标识，使构件的客户端可以准确地定位构件的位置，并请求服务。这就跟构件冗余系统产生冲突，冗余系统要求所有构件都要有主备节点，并且要求其主备模式对构件的客户端是透明的。这样，支持主备构件的寻址服务就成为系统不可缺少的基础服务，它可以解析客户的寻址请求，并把服务请求转发给主节点构件。

支持冗余的构件本身，为了满足苛刻的系统切换性能要求，必须针对具体情况特别设计。但有一点是共同的，就是主备构件的数据同步。在任何情况下，当主节点故障，备节点接管后，要能够保持与主节点故障前同样的内部状态信息。一种情况是主备节点中，同时只有一个节点从外部获得信息并对外提供服务，这样主备节点之间的数据同步，就需要同步所有的动态数据，而且只能通过主备节点间的通讯实现。由于主备节点通常不在相同的物理位置上，其间的通讯只能通过网络实现，这样就必须保证主备节点间数据同步的高效，不能占用大量的网络带宽。另一种情况是主备节点可以同时从外部获得信息，但同时只有一个节点对外提供服务，这样主备节点间的数据同步就会减少，只需要同步少量运行状态信息，但同样会有缺点，它要求信息提供者可以支持同时给主备节点提供相同的信息。

1，平衡主节点故障允许时间T1和主备节点切换时间T2。由于对于整个系统而言，需求被定位在节点的故障允许时间T。当T1太长、T2太短时，系统用来监视主备节点运行状态的消耗就少些，但对主备节点的切换性能要求高，这只有在主备节点间数据同步很充分的时候，才能做到，所以就提高了对数据同步要求。

2，减少需要同步的数据量。一方面，对构件信息进行良好归类，分离出静态信息和可以自行获得的信息，不需要对这些信息进行同步。另一方面，增大构件的尺寸，把内部联系紧密的构件聚合成较大的构件，这样就减少了需要跟外部交换的信息，也可以减少需要同步的数据量。