在 paxos 中主要有三個角色，分別為 proposer提案者、acceptor表決者、learner學習者。paxos 演算法和 2pc 一樣，也有兩個階段，分別為 prepare 和 accept 階段。
proposer提案者：負責提出 proposal，每個提案者在提出提案時都會首先獲取到乙個 具有全域性唯一性的、遞增的提案編號n，即在整個集群中是唯一的編號 n，然後將該編號賦予其要提出的提案，在第一階段是只將提案編號傳送給所有的表決者。
acceptor表決者：每個表決者在 accept 某提案後，會將該提案編號n記錄在本地，這樣每個表決者中儲存的已經被 accept 的提案中會存在乙個編號最大的提案，其編號假設為 maxn。每個表決者僅會 accept 編號大於自己本地 maxn 的提案，在批准提案時表決者會將以前接受過的最大編號的提案作為響應反饋給 proposer 。
下面是 prepare 階段的流程圖，你可以對照著參考一下。
當乙個提案被 proposer 提出後，如果 proposer 收到了超過半數的 acceptor 的批准（proposer 本身同意），那麼此時 proposer 會給所有的 acceptor 傳送真正的提案（你可以理解為第一階段為試探），這個時候 proposer 就會傳送提案的內容和提案編號。
表決者收到提案請求後會再次比較本身已經批准過的最大提案編號和該提案編號，如果該提案編號 大於等於 已經批准過的最大提案編號，那麼就 accept 該提案（此時執行提案內容但不提交），隨後將情況返回給 proposer 。如果不滿足則不回應或者返回 no 。
當 proposer 收到超過半數的 accept ，那麼它這個時候會向所有的 acceptor 傳送提案的提交請求。需要注意的是，因為上述僅僅是超過半數的 acceptor 批准執行了該提案內容，其他沒有批准的並沒有執行該提案內容，所以這個時候需要向未批准的 acceptor 傳送提案內容和提案編號並讓它無條件執行和提交，而對於前面已經批准過該提案的 acceptor 來說 僅僅需要傳送該提案的編號 ，讓 acceptor 執行提交就行了。
而如果 proposer 如果沒有收到超過半數的 accept 那麼它將會將 遞增 該 proposal 的編號，然後 重新進入 prepare 階段 。
其實就有點類似於兩個人吵架，小明說我是對的，小紅說我才是對的，兩個人據理力爭的誰也不讓誰??。
比如說，此時提案者 p1 提出乙個方案 m1，完成了 prepare 階段的工作，這個時候 acceptor 則批准了 m1，但是此時提案者 p2 同時也提出了乙個方案 m2，它也完成了 prepare 階段的工作。然後 p1 的方案已經不能在第二階段被批准了（因為 acceptor 已經批准了比 m1 更大的 m2），所以 p1 自增方案變為 m3 重新進入 prepare 階段，然後 acceptor ，又批准了新的 m3 方案，它又不能批准 m2 了，這個時候 m2 又自增進入 prepare 階段。。。
就這樣無休無止的永遠提案下去，這就是 paxos 演算法的死迴圈問題。
一致性演算法 Paxos
paxos是一種基於訊息傳遞的分布式一致性演算法，由leslie lamport 萊斯利 蘭伯特 於1990提出。是目前公認的解決分布式一致性問題的最有效演算法之一。paxos協議是乙個解決分布式系統中，多個節點之間就某個值 提案 達成一致 決議 的通訊協議。它能夠處理在少數節點離線的情況下，剩餘的...
一致性協議
節點在進行事務處理過程中保持原子性和一致性而設計的一種演算法。1.事務詢問。2.執行事務。3.各參與者向協調者反饋事務詢問的響應。理解 類似協調者組織各參與者對一次事務操作進行投票表態的過程。假如參與者全部反饋yes 1.傳送提交請求 2.事務提交 3.反饋事務提交結果 4.完成事務。假如任何乙個參...
一致性協議
在分布式系統中，每乙個機器節點雖然都能夠明確地知道自己在進行事務操作過程中的結果是成功或失敗，但卻無也直接獲取到其他分布式節點的操作結果。因此，當乙個事務操作需要跨越多個分布式節點的時候，為了保持事務處理的acid特性，就需要引人乙個稱為 協調者 的元件來統一排程所有分布式節點的執行邏輯，這些被排程...