【分佈式協調器】Paxos的工程實現-cocklebur簡介（二）

Cocklebur集羣的工做原理

　　在集羣正常工做時，整個集羣只會有一個Leader，其餘都是Follower。Client能夠註冊到某個Follower，固然也能夠註冊到Leader，爲了減輕Leader壓力，通常要選擇註冊到Follower。讀操做直接向Follower請求數據，而寫數據則直接向Leader提交請求（在Client註冊到Follower時已經得知當前的Leader的地址信息並緩存在Client本地，若是Client提交寫操做時發現目標主機已經不是Leader則將從新向Follower詢問Leader地址）。這種狀態下的集羣，Leader和Follower的狀態（維護的數據）知足最終一致性，而Leader擁有最新數據。

 

圖1、Cocklebur對外服務示意圖

　　注意，因爲最終一致性可能會致使Follower的數據更新延遲，對於整個集羣來講，讀數據時必然是延遲的，可是寫數據時Leader是必經之路，Leader能夠保證數據永遠都是最新的。因此寫當一個Client讀到延遲信息時發出特定目的寫操做時可能會失敗，但最終集羣的數據必定不會發生錯誤。

　　這就好像是你明明看到一個空的座位（讀取數據），當你要去坐的時候發現已經有人作了（嘗試要寫數據時，由於坐位子至關因而改變了座位的狀態）。這實際上對於座位來講並無什麼不合適的，由於誰先來的就應該是誰坐，而不是誰先看到就誰坐，由於看到並不算改變了它的狀態。因此經過這個例子，你能夠想一想分佈式鎖的場景。

Cocklebur主要功能模塊

而從cocklebur整體設計來看，其主要功能模塊以下圖所示：

 

圖2、Cocklebur基礎功能模塊

　　除了Thrift RPC序列化框架是第三方庫以外，其餘cocklebur不依賴其餘庫。而負責通訊這部分屬於十分基礎的技術，故不詳細介紹。另外你們能夠看到，cocklebur並無實現ACL（訪問控制列表，訪問權限相關），其實ACL能夠在數據操做模塊完成，本人時間有限因此就沒有實現ACL。以後的博客也主要圍繞上面四塊展開，介紹完功能模塊設計，就開始介紹一些主要的控制流程。

　　類Paxos選舉算法：目前Paxos的工程實現都不是Paxos原版，都是在其基礎上進行了化簡和改變。這樣有助於節約帶寬、化簡設計等等。該部分主要功能就是負責集羣啓動選舉Leader，以及當集羣不構成集羣對外服務條件時進行從新選舉。最終目的就是儘量讓集羣最快的對外服務。那麼什麼是集羣對外服務條件呢？那就是當前有Leader且Leader與其領導的Followers可以組成一個多數派（超過集羣節點半數）。

　　DataTree目錄結構：內存版的文件系統或者指的是一個數據結構。分佈式鎖以及名字空間、共享文件就是經過這樣的數據結構去實現的。其實這個數據結構並非很難理解，由於Tree這種結構很擅長去組織層次化的東西，正如xml，json，文件目錄那樣應用普遍。

　　日誌快照系統：用於爲每一個節點容災考慮設計，事實上光寫日誌就能夠保證容災，快照是爲了更快的去恢復當前內存狀態，就像你玩遊戲的檢查點（check point），下次開機玩就不用從第一關開始了。

　　數據操做的Client/Server：一方面集羣要對外服務，提供Client和Server。另外一方面，集羣節點之間內部同步數據時也須要使用這些組件。另外註冊-通知機制（觀察者模式）也是這部分實現的。