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

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

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

CAP

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

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

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

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

當(dāng)然，安全攻擊會試圖破壞CAP的這些元素。

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

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

Paxos

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

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

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

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

拜占庭容錯（BFT）

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

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

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

提交協(xié)議

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

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

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