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

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

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

CAP

任何網(wǎng)絡共享數(shù)據(jù)系統(tǒng)（例如Web）只能提供3種可能屬性中的2種，如下所示：

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

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

3.分區(qū)（P）：網(wǎng)絡分區(qū)容錯，使得服務器無法分區(qū)為非通信組。

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

復制和協(xié)調(diào)

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

Paxos

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

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

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

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

拜占庭容錯（BFT）

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

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

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

提交協(xié)議

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

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

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