開發可靠的分布式系統的一個基本挑戰是支持執行共同任務所需的分散實體的合作，即使某些這些實體或它們之間的通信失敗。需要確保服務操作的順序，并避免對分布式資源進行分區，以便形成一個整體的“協調”資源組。

狀態機復制或狀態機方法是通過復制服務器和協調客戶端與服務器副本的交互來實現容錯服務的通用方法。該方法還為理解和設計復制管理協議提供了一個框架?；镜南到y抽象是狀態機的抽象，使得狀態機的輸出完全由它處理的請求序列決定，而與時間或其他活動無關。系統。復制可以是主動的、半主動的、被動的或惰性的。

應該注意的是，理想情況下，人們希望共同實現高可用性、一致性和完全協調，以消除分布式資源集的任何分區。但是，CAP斷言的作用是：

CAP

任何網絡共享數據系統（例如Web）只能提供3種可能屬性中的2種，如下所示：

1.一致性（C）：相當于擁有數據的單個最新副本，即每個服務器對每個請求返回正確的響應。

2.可用性（A）：每個請求最終收到響應的數據。

3.分區（P）：網絡分區容錯，使得服務器無法分區為非通信組。

當然，安全攻擊會試圖破壞CAP的這些元素。

復制和協調

為了提供一致和一致的行為（在值和順序上），分布式資源使用各種類型的副本管理，即協調模式。這是表征任何分布式系統功能的關鍵協調機制。決定特定機制的因素取決于系統同步模型的類型、組通信的類型，尤其是所考慮的擾動（故障或攻擊）的性質。這些機制可以是簡單的投票或領導者選舉過程（例如，環形算法，欺凌），也可以是更復雜的共識方法來處理崩潰或拜占庭5行為。數據庫事務的提交協議與提供經過驗證的訪問控制的憑據管理和PKI基礎結構的方案在這里相關。我們簡要描述了一組廣泛使用的模式，并參考閱讀器以完整覆蓋。分布式系統中的授權和身份驗證也在身份驗證，授權和責任CyBOK知識領域中進行了討論。

Paxos

為了避免分布式實體進行不協調的行動或未能響應的情況，Paxos已經開發出來，這是一組隱式領導者選舉協議，用于在異步設置中解決共識。Paxos通過讓所有參與者在初始階段提出一個達成一致的價值來解決共識問題。在第二階段，如果多數人同意某個價值，則提出該價值的過程隱含地成為領導者，并達成一致。對下一個值重復相同的過程，以就一系列值達成共識。

眾所周知，該方案僅在非常特定的情況下才提供活體。在這種情況下，流程繼續無限期地提出價值，并在初始階段保持阻塞，因為無法形成多數并且從未取得進展。然而，這種情況在實踐中很少發生，Paxos仍然是使用最廣泛的協調協議之一。

由于在第二階段只需要多數人即可達成共識，因此即使在恢復的情況下，該協議也對崩潰具有容忍度。這是了不起的，因為只要大多數進程沒有失敗，就能夠達成共識。

雖然Paxos協議有多種實現方式，但由于其固有的復雜性，它以難以實現和構建中間件而聞名。為此，提出了一種類似于Paxos的協議RAFT來提供相同的保證。RAFT最近因其更簡單的設計而越來越受歡迎。通過與Paxos的比較，解釋了RAFT協議開發背后的動機以及它是如何工作的。

拜占庭容錯（BFT）

攻擊和其他故意中斷不一定遵循良性遺漏、時間或崩潰的語義。為了容忍任意惡意行為，拜占庭容錯（BFT）協議使用協調復制來保證操作的正確執行，只要在大多數三分之一的進程受到損害并表現出任意（即拜占庭，參見第5節）行為。

在BFT中，進程以輪次交換它們從彼此那里收到的值。達成共識所需的輪數取決于系統中受損參與者的數量。請注意，由于該協議是輪次運行的，因此它被歸類為同步協調協議。已經表明，FLP不可能的結果是在異步通信的情況下不可能達成共識。由于同步通信的必要性以及處理拜占庭故障所需的消息交換開銷相當高，BFT協議主要應用于特定的關鍵應用。然而，通過加強對同步、確定性和妥協數量的一些基本假設，正在進行多種實際BFT優化的嘗試。Google File System（Chubby）和Amazon Web Services（AWS）實現了Paxos和部分BFT功能。同樣重要的是要強調BFT不僅因為所需輪數的消息復雜性而昂貴。處理f惡意故障所需的節點數（>f）也是昂貴的，即f是由對手控制的節點數。

從安全角度來看，BFT協議能夠容忍任意惡意行為，因此構成了構建入侵容忍系統的有吸引力的構建塊。值得注意的是，這些協議考慮了受感染實體的數量。當面對惡意攻擊者時，相同的副本是不夠的，因為它們表現出相同的漏洞。如果其他副本相同，則可以破壞一個副本的惡意攻擊者可以輕松破壞它們。需要復制和多樣性（或不同的保護方法）。

提交協議

許多應用程序，例如數據庫，需要跨復制的數據或操作進行排序，其中所有參與者都同意執行相同的正確結果（即提交）或不執行任何操作–原子性屬性。因此，作為一種專門的共識形式，需要分布式協調器定向算法來協調參與分布式原子事務的所有進程是否以提交或中止（回滾）事務。

兩階段提交（2PC）是這種原子提交協議的一個簡單示例。該協議繼續進行從領導者到所有要提交的客戶端的廣播查詢。隨后是來自每個客戶端的確認（提交或中止）。在收到所有響應時，領導者會通知所有客戶端關于提交或中止的原子決策。即使在許多故障情況下（涉及進程、網絡節點或通信故障等），該協議也能實現其目標，因此被廣泛使用。基于日志記錄協議狀態的方法用于支持恢復。經典的2PC協議對可能導致不一致的協調器故障提供有限的支持。

為了解決這個問題，開發了三階段提交（3PC）協議。3PC協議本質上是BFT協議的擴展，并增加了第三個通信階段，以幫助領導者做出中止的決定。這需要更高的消息傳遞和日志記錄開銷來支持恢復。雖然與BFT相比，3PC是一種更強大的協議，但由于消息傳遞開銷及其對網絡分區的敏感性（即P大寫）。在實踐中，系統使用BFT是為了簡單性，或者使用Paxos協議來表示其魯棒性。