論文閱讀筆記 – Paxos made live

作者：劉旭暉 Raymond 轉載請註明出處

Email：colorant at 163.com

BLOG：http://blog.csdn.net/colorant/

更多論文閱讀筆記 http://blog.csdn.net/colorant/article/details/8256145

關鍵字

Paxos, 實現,可靠性，效能，Chubby

 

==
目標問題 ==

 

基於Paxos機制，構建一個可靠的容錯資料庫系統。Paxos理論和實際實現之間有很多的gap，如何解決這些問題並構建出一個實際可用的系統。實際中作為Chubby的底層Log機制的一個實現

 

==
核心思想 ==

 

將Paxos邏輯由理論變成實踐中上線的產品，需要解決眾多的問題，涉及到可靠性，效能等方面的眾多問題。尤其是可靠性方面，現實系統中存在各種各樣的系統失效問題，原有的Paxos理論邏輯基於的假設前提往往會被破壞，要解決這些問題，就需要方法來檢測和控制各種失效。

 

Multi-Paxos：Paxos邏輯是對一個單獨問題的獨立的決策過程，實際的系統需要一系列的Paxos過程來推動系統的運作，通過最佳化（比如保持一個相對穩定的Leader），可以在串聯的多個Paxos過程中，節省下一個獨立Paxos過程中所需要的一些步驟（如跳過下一個Paxos過程的Prepare階段），加快Paxos的決策過程。

 

Leader角色的維護：要保持相對穩定的Leader，同時要防止單點失效和不影響讀寫效能，引入了基於timeout的契約（Master
Lease）。一方面可以重選Leader，另一方面也用於在讀資料過程中，保證Master本機資料的最新（沒有Lease的replica不能更新資料）

 

磁碟失效問題的解決：Paxos邏輯中很重要的一個前提就是每個參與決策的Replica需要記住一些之前作過的承諾，這些承諾或Log記錄在磁碟上儲存已用於服務重構。但是如果這些記錄損壞了，就會導致Paxos邏輯的前提被打破，進而導致系統無法正確運轉。

• 失效的原因很多，可能是檔案錯誤，或是完全丟失。前者可以通過各種校正手段來檢測，後者通過在Distributed File System（GFS）中維護一個標記來判別是否之前存在過可用檔案。
• 失效的解決，基本上是通過Catch up，一方面從其它Replica中擷取但前最新資料，另一方面直到觀察獲得整個系統的下一個完整的Paxos過程之前，自身不再參與Paxos決策過程

 

Snapshot快照：引入snapshot快照的目的是為了縮短資料重構時Log回放的代價，減少磁碟開銷等。這同時也會引入額外的複雜性，比如快照與LOG的一致性，快照的丟失和恢複以及此期間可能遇到的各種問題等

 

==
實現 ==

 

實現中，為了減少開發複雜度和保證系統的正確性，採用了各種手段。比如隔離模組關係，拆分出獨立的狀態機器，寫了專門的工具用於從自訂語言中產生狀態機器的實際C++代碼。

 

再有在一個容錯系統中，底層的錯誤很可能被本身的容錯機制所屏蔽了，加大了調試的難度。因此開始就是以測試為嚮導的，代碼中大量的Assert。同時開發了各種層面的測試載入器，用於在各個層級中可重現的植入各種錯誤情況。此外還有各種運行時的校正機制來檢測不可預知的一致性錯誤，而LOG機制本身也有助於回放錯誤的過程。

 

==
相關研究，項目等 ==

 

Paxos /Chubby

 

==
其它 ==

 

總之，這篇文章就是Google在Chubby中運用Paxos來實現容錯資料庫LOG機制時遇到的各種實際問題的解決方案的經驗總結。也提出了容錯系統開發的方法建議。