背景
長時間以來，由於軟體的固有特性：不會磨損、錯誤如果不被發現就永遠存在、相同的版本在相同的條件下錯誤也是相同的。促使人們認為軟體的冗餘是沒有意義的。但隨著軟體系統的複雜性增大、分散式套用的廣泛部署，使軟體賴以運行的環境越來越複雜，運行環境的可靠性必須通過冗餘實現。這樣就使得，雖然軟體本身冗餘沒有意義，但要在冗餘的硬體及作業系統中運行，軟體也必須支持冗餘功能。分散式軟體的冗餘特性就這樣被重視起來。
需求
在關鍵控制系統中，比如衛星控制系統、飛機及機場控制系統、鐵路控制系統等，對系統的可靠性有苛刻地要求。在這些系統中，所有組件都要求有冗餘設計，包括任何硬體及軟體環節，要求任何單點故障不影響系統正常運行，即使是關鍵節點故障，系統中其他部分也要求具備基本的應急功能。
在系統中，抽象層次越高的節點，其支持更多的接口，包含更多的信息和處理邏輯，所以複雜度也越高。同時，複雜度越高的節點，支持冗餘的難度越大。這就是硬體節點容易冗餘，而軟體節點不容易冗餘的原因。
對冗餘節點的最基本的要求是，在主節點發生故障時，備用節點自動接管主節點，完成所有的功能及提供的所有的服務。對冗餘的更進一步的要求是，在主備節點切換的過程中，不允許有信息的丟失，切換過程中的發生的任何事件都不允許丟失。
對冗餘功能的性能要求分兩個方面，一個是主節點故障允許時間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，減少需要同步的數據量。一方面，對構件信息進行良好歸類，分離出靜態信息和可以自行獲得的信息，不需要對這些信息進行同步。另一方面，增大構件的尺寸，把內部聯繫緊密的構件聚合成較大的構件，這樣就減少了需要跟外部交換的信息，也可以減少需要同步的數據量。
