一. 前言
《Paxos Made Live - An Engineering Perspective》一文爲谷歌公司所寫，主要內容爲paxos算法工程領域實踐遇到的問題和經驗教訓。關於Paxos共識算法的介紹可以參看前文，算法本身簡潔而優雅，提供了很高的靈活性。但是就是因爲很高的靈活性，導致了實現起來會異常複雜。於此相反的是raft做了很多嚴格的規定，因此實現起來會容易很多，也更易於理解。谷歌在實現Paxos並不順利，論文中稱之爲“Non-trivial task”，主要問題有
- Paxos算法僞代碼可以簡單地描述，但是實際卻需要編寫幾千行C++代碼，因爲將算法變爲實際的工程，需要加入很多的特性和優化。
- 算法提供了容錯性數學上的證明，但是在實際中驗證需要做很多工作
- 算法在容錯方面僅做了簡單地考慮，在實際中會遇到“成噸的”其他問題，如算法的錯誤，編程的BUG，操作問題，硬件故障等等。這些都是算法假設去掉了的，爲了保證真實系統的可靠性，這裏必須採用很多不同的方式解決。
- 真實系統不像算法一樣精確，而是一直在變化之中，因此需要再算法每個階段都能容忍網絡的變化。
本文就谷歌提出的以上問題來分析論文中谷歌是如何解決這些問題的。
二. 應用背景
工程實踐一種算法當然是爲了應用，因此應用背景是前提條件，拋開特定場景就無法理解很多工程上的做法。在谷歌的大數據生態圈中，GFS用於存儲大量的網頁文件，MapReduce用於對數據進行處理，BigTable數據庫用於存儲網頁文件索引、信息。GFS和BigTable有着共同的使用場景：大量廉價低性能計算機組成的分佈式系統，因此如何保持Log以及各種信息的一致性至關重要。Chubby就是起到該作用，而Chubby的核心就是Paxos算法。
如下圖所示是Chubby的系統框架，Chubby Library是對Paxos的實現，上層封裝了Chubby Client和服務器進行通信。圖中間是Chubby的核心所在，主要由容錯日誌和容錯數據庫組成。其中容錯日誌基於Paxos實現，保證每個機器上運行的Chubby中日誌內容相同。容錯數據庫包括了本地快照和數據庫操作的replay-log，原理類似於MySQL的redo-log，可以在共識算法發現異常時對數據操作進行方便的回退或增加。
三. 實現細節
1. 處理磁盤故障
磁盤的意外故障會造成文件內容的改變或者文件不可讀。爲此我們需要磁盤故障檢測以及修復的功能。磁盤故障檢測主要包括：
（1）在文件中存儲文件目錄的校驗和，如果校驗和變化則表示磁盤出現故障
（2）在文件複製時，如果出現後面的問題，複製的結果是一個空磁盤，我們對此做GFS的標記，檢測到該標記則表明出現了無法訪問的文件，即磁盤出現故障
磁盤修復主要方法是參與Paxos但是不投票，利用catch-up機制複製文件到本機，不給與promis或者ack回覆，直到完成了所有文件的修復爲止。
2. master租賃機制（Master Leases）
在Paxos運行過程中，master一旦選舉成功就具有了發起更新的權力。但是由於Paxos的靈活性或者由於分區等原因，可能會產生多個master，從而造成數據的不一致性。因此我們需要保證任意時刻只有一個master的存在。
爲了實現master的唯一性，我們需要做以下限制：
（1）在master租賃期內，其他的成員不允許提交值
（2）當master斷開連接的時候，選舉新的master的序列大於舊的序列。舊序列即使連上了，master也會自我解除權限。注意這裏和paxos算法原文中的優化措施相反，原文中採取的是舊master連上了之後自增重新成爲master。這種做法對於網絡情況差、經常斷線的網絡會導致master不停地更換，使得網絡效率極低。
3. 全局邏輯時鐘機制（Epoch Numbers）
這裏採取了類似於Lamport時鐘的邏輯時鐘來實現分佈式消息的同步問題。
4. 會員組機制（Group Membership）
考慮到複雜多變的網絡情況、易出現故障的磁盤，我們需要時刻記錄當前的Paxos的參與者。對於單個Paxos，自身其實就具有記錄功能，但是對於多Paxos的情況，最佳選擇是額外實現一個會員組模塊存儲當前的參與者。
5. 快照功能
僅記錄日誌的話會存在兩個問題：
- 如果出現錯誤需要回復會需要不停地查找，工作量極大
- 日誌沒有上限，會磁盤會造成巨大的負擔甚至崩潰
因此，在這裏我們也採用了快照技術。
（1） 快照和日誌需要保持一致性，每一個快照需要擁有和其內容相關的容錯日誌的信息，爲此我們設計了快照句柄，快照句柄包括了Paxos相關的所有信息。當創建快照時，我們同時創建快照句柄。當需要使用快照恢復文件的時候，根據句柄獲取信息，結合快照和日誌進行恢復
（2）快照的創建需要消耗一定的時間，凍結日誌創建快照會帶來一定的延遲。因此我們分三個步驟完成快照：首先客戶端決定創建快照，請求快照句柄。接着客戶端創建一個線程來創建自己的快照，最終快照創建完後，客戶端通知框架，並傳輸快照句柄。
（3）創建快照可能會失敗：客戶端未通知框架的時候，從框架的角度是不知道已經產生了新的客戶端快照的，因此客戶端可以檢驗其完整性並丟棄。僅僅當框架收到句柄時，該快照纔算生效
四. 總結
論文中還有提到一些如遇到的意外問題以及對算法性能效果的測試，在此不做展開記錄了，推薦查看原文深入學習。