1.zookeeper的底層演算法機制
前面有說過2pc演算法和paxos演算法，具體見zookeeper的底層演算法機制(上)。在了解zookeeper的演算法之前，先了解一下拜占庭將軍問題。
2.拜占庭將軍問題
拜占庭帝國有許多支軍隊，不同軍隊的將軍之間必須制訂乙個統一的行動計畫，從而做出進攻或者撤退的決定，同時，各個將軍在地理上都是被分隔開來的，只能依靠軍隊的通訊員來進行通訊。然而，在所有的通訊員中可能會存在叛徒，這些叛徒可以任意篡改訊息，從而達到欺騙將軍的目的。
這就是著名的「拜占庭將軍問題」。實際上拜占庭將軍問題是乙個分布式環境下的協議問題，拜占庭帝**隊的將軍們必須全體一致的決定是否攻擊某一支敵軍。
拜占庭將軍問題應用在分布式環境下，就是在通道不可靠當的情況下，如何就某個協議達成一致性問題。
3.zookeeper底層演算法原理
zookeeper底層的演算法是基於zab協議的。
3.1 zab協議
zab(zookeeper atomic broadcast)協議是分布式協調服務服務zookeeper專門設計的一種支援崩潰恢復的原子廣播協議，是專門為zookeeper設計的崩潰恢復原子廣播演算法，是基於2pc演算法。
zookeeper的各個節點之間的通訊協議是通過netty的。
3.2 協議介紹
zab協議包括兩種基本模式,分別是：
a.訊息原子廣播(保證資料的一致性)
b.崩潰恢復(解決2pc演算法的單點問題)
3.3訊息原子廣播
zookeeper主要是通過zab協議實現分布式環境資料的一致性，zookeeper實現了一種主備模式的系統架構來保持集群中各副本之間資料的一致性，實現分布式資料一致性的這一過程稱為訊息廣播（原子廣播 ）。
zookeeper使用乙個單一的主程序（leader伺服器）來接收並處理客戶端的所有事務請求，並採用zab的原子廣播協議，將伺服器資料的狀態變更以事務proposal的形式廣播到所有的副本程序（follower或observer)上去。即：所有事務請求必須由乙個全域性唯一的伺服器來協調處理，這樣的伺服器被稱為leader伺服器，而餘下的其他伺服器則成為follower伺服器或observer。
leader伺服器負責將乙個客戶端事務請求轉換成乙個事務proposal（提議），並將該proposal分發給集群中所有的follower伺服器。之後leader伺服器需要等待所有follower伺服器的反饋，一旦超過半數的伺服器（follower+leader伺服器）本身進行了正確的反饋後，那麼leader就會再次向所有的follower伺服器分發commit訊息，要求其進行提交。較比與2pc演算法，zab引入了過半性思想。
需要明確的是，zab協議中涉及的二階段提交過程則 與2pc不同。在zab協議的二階段提交過程中，我們可以在過半的follower伺服器已經反饋ack之後就開始提交事務proposal了，而不需要等待集群中所有的follower伺服器都反饋響應。
在這種簡化了的二階段提交模型下，是無法處理leader伺服器崩潰退出而帶來的資料不一致問題的，因此在zab協議中新增了另乙個模式，即採用崩潰恢復模式來解決這個問題。另外，整個訊息廣播協議是基於具有fifo特性的tcp協議來進行網路通訊的，因此能夠很容易地保證訊息廣播過程中訊息接收與傳送的順序性。
在整個訊息廣播過程中，leader伺服器會為每個事務請求生成對應的proposal來進行廣播，並且在廣播事務proposal之前，leader伺服器會首先為這個事務proposal分配乙個全域性單調遞增的唯一id，我們稱之為事務id（即zxid）。由於zab協議需要保證每乙個訊息嚴格的因果關係，因此必須將每乙個事務proposal按照其zxid的先後順序來進行排序與處理。
具體的，在訊息廣播過程中，leader伺服器會為每乙個follower伺服器都各自分配乙個單獨的佇列，然後將需要廣播的事務proposal依次放入這些佇列中去，並且根據fifo策略進行訊息傳送。每乙個follower伺服器在接收到這個事務proposal之後，都會首先將其以事務日誌的形式寫入到本地磁碟中去，並且在成功寫入後反饋給leader伺服器乙個ack響應。當leader伺服器接收到超過半數follower的ack響應後，就會廣播乙個commit訊息給所有的follower伺服器以通知其進行事務提交，同時leader自身也會完成對事務的提交，而每乙個follower伺服器在接收到commit訊息後，也會完成對事務的提交。
3.4 崩潰恢復
當整個服務框架在啟動過程中，或是當leader伺服器出現網路中斷、崩潰退出與重啟等異常情況時，zab協議就會進入恢復模式並選舉產生新的leader伺服器。
當選舉產生了新的leader伺服器，同時集群中已經有過半的機器與該leader伺服器完成了狀態同步之後，zab協議就會退出恢復模式。其中，所謂的狀態同步是指資料同步，用來保證集群中存在過半的機器能夠和leader伺服器的資料狀態保持一致。
當集群中已經有過半的follower伺服器完成了和leader伺服器的狀態同步，那麼整個服務框架就可以進入訊息廣播模式了。
當一台同樣遵守zab協議的伺服器啟動後加入到集群中時，如果此時集群中已經存在乙個leader伺服器在負責進行訊息廣播，那麼新加入的伺服器就會自覺地進入資料恢復模式：找到leader所在的伺服器，並與其進行資料同步，然後一起參與到訊息廣播流程中去。
zookeeper設計成只允許唯一的乙個leader伺服器來進行事務請求的處理。leader伺服器在接收到客戶端的事務請求後，會生成對應的事務提案並發起一輪廣播協議；而如果集群中的其他機器接收到客戶端的事務請求，那麼這些非leader伺服器會首先將這個事務請求**給leader伺服器。
當leader伺服器出現崩潰退出或機器重啟，亦或是集群中已經不存在過半的伺服器與該leader伺服器保持正常通訊時，那麼在重新開始新一輪的原子廣播事務操作之前，所有程序首先會使用崩潰恢復協議來使彼此達到乙個一致的狀態，於是整個zab流程就會從訊息廣播模式進入到崩潰恢復模式。
乙個機器要成為新的leader，必須獲得過半程序的支時由於每個程序都有可能會崩潰，因此，在zab協議執行過程中，前後會出現多個leader，並且每個程序也有可能會多次成為leader。進入崩潰恢復模式後，只要集群中存在過半的伺服器能夠彼此進行正常通訊，那麼就可以產生乙個新的leader並再次進入訊息廣播模式。舉個例子來說，乙個由3臺機器組成的zab服務，通常由1個leader、2個follower伺服器組成。某乙個時刻，假如其中乙個follower伺服器掛了，整個zab集群是不會中斷服務的，這是因為leader伺服器依然能夠獲得過半機器（包括leader自己）的支援。
3.5 zab協議的優點
zab協議對於事務的提交，滿足過半性的好處罪域解決zk伺服器之間的同步阻塞問題。而且底層支援崩潰恢復，避免leader的單點故障問題。zab協議可以確保zookeeper伺服器集群的資料的一致性，即客戶端無論從哪台zk伺服器讀取，資料都是一致的。
Zookeeper的底層演算法機制 上
1.關於分布式環境下資料一致性問題 對於在分布式環境下的資料一致性問題，主要目的是確保分布式環境下每個節點的資料的一致性，如果在某個節點上資料進行更新後，兒其他的節點或某幾個節點的資料沒有進行更新，那麼就會造成髒資料的問題，這個就是在分布式環境下的資料的一致性問題。那麼為了解決分布式環境下的資料一致...
objective c底層 runtime機制
runtime是oc的真面目。oc底層的一套c語言api.unsigned int count 獲取屬性列表 objc property t propertylist class copypropertylist self class count for unsigned int i 0 i 獲取方...
虛擬機器中ZooKeeper的安裝
zookeeper的安裝 需要提前準備好jdk環境 解壓檔案到hadoop目錄下 建立zookeeper目錄並建立軟連線 在zookeeper目錄下建立zkdata 目錄修改zookeeper的配置檔案 cd opt bigdata hadoop zookeeper conf mv zoo.samp...