一、問題產生的背景
在分布式系統中，必然會存在服務宕機 或網路異常 （如網路延遲、訊息亂序、訊息丟失等）等狀況。paxos基於容錯的分布式環境，實現在集群內部對某個值達成最終一致的分布式演算法。【注1】服務不存在拜占庭將軍問題（不存在叛徒），也即集群內的機器可以隨時發生宕機重啟，但不能做出有違約定的行為。
【注2】集群中的某個值可以是一條命令、一組資料等，value對每個應用場景具有不同的意義
二、相關概念
1、數學符號
2、性質
三、推導過程
四、演算法模型
首先，假設每一位議員的律簿的正面用於按照順序記錄已經通過的法令，比較正式，不可更改。律薄的背面(便簽的作用，可以擦寫)用於記錄不連續的法令，以後再謄抄到正面。另外，律薄的背面還要記錄幾個關於投票過程的重要資訊：
v: 議員自己上次完成投票的投票編號
b: 新一輪投票中接收到的新投票編號
下面就講解這6個步驟：
1、議員p根據自己律薄的記錄，選擇乙個新的投票編號b(b>v)。然後給大廳的其他議員，傳送通知訊息nextballot=b。
【注】定理2
2、議員q收到p傳送的訊息以後，找到自己在b之前參與的投票編號v(b>v)，並返回v；如果不存在v就返回null。返回訊息lastvote(b)=v 。注意，此時q會鎖定v~b之間的投票，即：議員q只會對b進行投票。
【注】b3性質保持，鎖定maxvote
3、議員p收到大廳內所有議員的step2響應彙總成乙個集合v，根據b3法則，選擇出本輪投票的法令d，然後，給大廳內所有議員傳送開始投票的訊息beginballot (b, d)。
【注】定理2
4、議員q開始表決(投票就表示贊同)，修改自己律薄上記錄的上次投票編號v=b。如果不表決可是因為：收到另乙個議員p1發起的新投票編號b1(b1>b)，這樣在step2中鎖定範圍包括了b，所以，此時不能完成b輪投票；或者因為睡著了而沒有投票等等。
5、議員p收到大廳所有議員的投票，那麼法令d表決通過，在律薄上記錄法令d，然後傳送success(d)訊息。
6、議員q在律薄上記錄法令d。
【注】以上六個步驟，所有的角色都可以選擇執行或者不執行（網路異常或宕機等狀況），但不能違背規則（拜占庭將軍問題）
五、演算法改進
改進一：基礎協議
在初級協議的基礎上，增加了以下限制：
1.任意時間點，只能由一位牧師發起一輪投票。
2.在step2完成以後，議員q將鎖定所有小於b的投票，這比初級協議更為嚴格。
註解：這個階段新增的兩個約束，降低了多個議員同時發起多輪投票的混亂場景，保證了投票過程的一致性
改進二：完整的神會協議
基礎協議保證了一致性，但是無法保證投票的可進展性，如：議員p什麼時候發起投票，如果一直傻傻的等著，那麼什麼法令都無法通過；如果他是個急性子，未等到上一輪投票結束，又發起新的倫理，由於step2的鎖承諾的原因，新的投票會阻塞舊的投票，不斷發起新的投票，最後的結果還是沒有法令通過。那麼，完整協議需要解決的是協議的可進展性問題。
首先，需要選擇乙個**(president)。同時，假設經過一段時間後，會議沒有人員進出了，那麼就認為接下來的t分鐘內(原文未講解t的制定規則)通過選舉只會有一位**。選舉的方式就是每隔t-11分鐘(11分鐘是乙個議員處理訊息+傳遞訊息時間，也就是保證在t時間結束之前，完成一次名字交換)議員把自己的名字告訴大家，如果在t分鐘內，仍然沒有收到比自己更大的名字，那麼他就認為自己是**。
然後，**什麼時候該發起投票呢，投票頻率怎麼樣呢，所以，**需要知道每個步驟需要的時間。假設前面提到的6個步驟，每個議員處理訊息的時間至少需要7分鐘，訊息傳遞的時間至少需要4分鐘。那麼全程至少需要需要：7分鐘*6個步驟 + 4分鐘*5次訊息傳遞=62分鐘。但是，完成一輪投票的時間不是t-11+62分鐘，為什麼呢？接著說。
完整協議沒有機制保證**的律薄上一開始就記錄了最新的法令條紋和投票資訊，那麼按照b1規則，選出的投票編號b，有可能不是最大的，所以在step3之後，傳送投票表決的時候，會遭到其他議員的反對(step4)，告訴**最新的投票編號是b1(b1>b)，所以，完整協議完成一輪投票的時間，可能是t+99(44分鐘是**收到投票編號太小的訊息的時間，55分鐘是完成step1-6的總時間，但不包括step6本身執行時間)，為什麼說可能呢，因為這裡的44分鐘不是必須的。
最終，只要議會大廳的大門關閉t+99分鐘，就一定可以通過至少一部法令。
改進三：多法令並行的國會
1.自動補齊法令：**在step1選擇新投票編號b的時候，找到自己律薄中編號最大的法令n，然後傳送nextballot(b,n)給其他議員。當其他議員收到該訊息以後，議員會返回自己律薄中紀錄的》n的法令，同時向**請求自己缺少的法令；當然，如果議員律簿中最大的法令，那麼返回正常的lastvote(b)訊息。（階段四的投票編號衝突需要等到step4才發生，step5才能被**感知，所以，這裡的改進是非常有必要的。）
2.如何引入新法令：**引入新法令前，需要學習乙個多數集合(過半)的議員已經投過票的法令。所有通過的法令至少被乙個多數集合的議員投過票。所以，**可以檢視自己的律薄就知道當前的法令是否已經全部通過，然後就可以提議新的法令了。
3.簡化的投票：如果會議大廳的大門關閉，一段時間內沒有人員出入，那麼**和議員是固定的，這時候的投票就很簡單了，只需要step3-5即可以完成一輪投票。甚至**可將上一輪投票的step5訊息和這一輪的step3訊息合併為乙個訊息傳送，這就變成了是乙個高效的議會。
六、工程性問題
1.關於選擇乙個新**的問題：議員z出海捕魚半年後回到議會大廳，他立刻當選為新的**(因為他的名字的字母順序是最大的)，那麼在他開始發起投票之前，必須先學習這半年的法令，這將是乙個漫長的過程，而在此期間議會一直處於等待狀態。
3.官僚化：原文中提的這一點，我覺得和「法令的學習」是一致的。
4.法令的學習：隨著法令的增加，同一件事的新舊法令也越來越多，如何保證兩個農民能學習到一致的法令(或者有分歧時如何統一)，這就需要為每乙個領域指定一位議員做該領域的專家，負責解釋該領域的最新法令。
5.不誠實的議員和無心之失：這兩種情況都會導致議員之間法令的不一致，如何保證議會系統的自穩定性，很不幸，暫時還沒有被發掘。
6.選舉新的議員：由於法令需要過半數議員的同意才能通過，如果當前法令選舉了大量新的議員，而這些議員又無法參加議會(如：已故、長期出海等)，這樣議會就停擺了。
理解Paxos演算法的推導過程
paxos作為分布式系統的基石，一直都是cs領域的熱門話題，paxos號稱是最難理解的演算法。最近幾天一直在看paxos相關資料，發現paxos演算法執行過程很簡單，但如何推導出paxos演算法確實令人費解。網上有大量關於paxos的基本概念 演算法描述 推導過程等文章，所以關於paxos的基本概念...
Zookeeper與paxos演算法
一 zookeeper是什麼 官方說辭 zookeeper 分布式服務框架是apache hadoop 的乙個子專案，它主要是用來解決分布式應用中經常遇到的一些資料管理問題，如 統一命名服務 狀態同步服務 集群管理 分布式應用配置項的管理等。好抽象，我們改變一下方式，先看看它都提供了哪些功能，然後再...
Zookeeper與paxos演算法
一 zookeeper是什麼 官方說辭 zookeeper 分布式服務框架是apache hadoop 的乙個子專案，它主要是用來解決分布式應用中經常遇到的一些資料管理問題，如 統一命名服務 狀態同步服務 集群管理 分布式應用配置項的管理等。好抽象，我們改變一下方式，先看看它都提供了哪些功能，然後再...