❶ Zookpeer是什麼在系統中如何起作用
Zookeeper分布式服務框架是Apache Hadoop的一個子項目，它主要是用來解決分布式應用中經常遇到的一些數據管理問題。如：統一命名服務、狀態同步服務、集群管理、分布式應用配置項的管理等。
我們先看看它都提供了哪些功能，然後再看看使用它的這些功能能做點什麼。
簡單的說，zookeeper=文件系統+通知機制。
Zookeeper維護一個類似文件系統的數據結構：
每個子目錄項如 NameService 都被稱作為 znode，和文件系統一樣，我們能夠自由的增加、刪除znode，在一個znode下增加、刪除子znode，唯一的不同在於znode是可以存儲數據的。
客戶端注冊監聽它關心的目錄節點，當目錄節點發生變化（數據改變、被刪除、子目錄節點增加刪除）時，zookeeper會通知客戶端。
這個似乎最簡單，在zookeeper的文件系統里創建一個目錄，即有唯一的path。在我們使用tborg無法確定上遊程序的部署機器時即可與下遊程序約定好path，通過path即能互相探索發現，不見不散了。
程序總是需要配置的，如果程序分散部署在多台機器上，要逐個改變配置就變得困難。
可以把這些配置全部放到zookeeper上去，保存在 Zookeeper 的某個目錄節點中，然後所有相關應用程序對這個目錄節點進行監聽，一旦配置信息發生變化，每個應用程序就會收到 Zookeeper 的通知，然後從 Zookeeper 獲取新的配置信息應用到系統中就好。
集群管理無在乎兩點：是否有機器退出和加入、選舉master。
對於第一點，所有機器約定在父目錄GroupMembers下創建臨時目錄節點，然後監聽父目錄節點的子節點變化消息。一旦有機器掛掉，該機器與 zookeeper的連接斷開，其所創建的臨時目錄節點被刪除，所有其他機器都收到通知：某個兄弟目錄被刪除，於是，所有人都知道：它下船了。當然又會有新機器加入，也是類似：所有機器收到通知---新兄弟目錄加入，highcount又有了，有人上船了。
對於第二點，我們假設機器創建臨時順序編號目錄節點，每次選取編號最小的機器作為master就好。
有了zookeeper的一致性文件系統，鎖的問題變得容易。鎖服務可以分為兩類，一個是保持獨占，另一個是控制時序。
對於第一類，我們將zookeeper上的一個znode看作是一把鎖，通過createznode的方式來實現。所有客戶端都去創建 /distribute_lock 節點，最終成功創建的那個客戶端也即擁有了這把鎖。廁所有言：來也沖沖，去也沖沖，用完刪除掉自己創建的distribute_lock 節點就釋放出鎖。
對於第二類， /distribute_lock 已經預先存在，所有客戶端在它下面創建臨時順序編號目錄節點，和選master一樣，編號最小的獲得鎖，用完刪除，依次方便。
兩種類型的隊列：
1、 同步隊列，當一個隊列的成員都聚齊時，這個隊列才可用，否則一直等待所有成員到達。
2、隊列按照 FIFO 方式進行入隊和出隊操作。
第一類，在約定目錄下創建臨時目錄節點，監聽節點數目是否是我們要求的數目。
第二類，和分布式鎖服務中的控制時序場景基本原理一致，入列有編號，出列按編號。
Zookeeper中的角色主要有以下三類：
系統模型如圖所示：
Zookeeper的核心是原子廣播，這個機制保證了各個Server之間的同步。實現這個機制的協議叫做Zab協議。Zab協議有兩種模式，它們分 別是恢復模式（選主）和廣播模式（同步）。當服務啟動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數Server完成了和 leader的狀態同步以後，恢復模式就結束了。狀態同步保證了leader和Server具有相同的系統狀態。
為了保證事務的順序一致性，zookeeper採用了遞增的事務id號（zxid）來標識事務。所有的提議（proposal）都在被提出的時候加上 了zxid。實現中zxid是一個64位的數字，它高32位是epoch用來標識leader關系是否改變，每次一個leader被選出來，它都會有一個 新的epoch，標識當前屬於那個leader的統治時期。低32位用於遞增計數。
每個Server在工作過程中有三種狀態：
當leader崩潰或者leader失去大多數的follower，這時候zk進入恢復模式，恢復模式需要重新選舉出一個新的leader，讓所有的 Server都恢復到一個正確的狀態。Zk的選舉演算法有兩種：一種是基於basic paxos實現的，另外一種是基於fast paxos演算法實現的。系統默認的選舉演算法為fast paxos。先介紹basic paxos流程：
通過流程分析我們可以得出：要使Leader獲得多數Server的支持，則Server總數必須是奇數2n+1，且存活的Server的數目不得少於n+1.
選完leader以後，zk就進入狀態同步過程。
Leader主要有三個功能：
PING消息是指Learner的心跳信息；REQUEST消息是Follower發送的提議信息，包括寫請求及同步請求；ACK消息是 Follower的對提議的回復，超過半數的Follower通過，則commit該提議；REVALIDATE消息是用來延長SESSION有效時間。
Leader的工作流程簡圖如下所示，在實際實現中，流程要比下圖復雜得多，啟動了三個線程來實現功能。
Follower主要有四個功能：
Follower的消息循環處理如下幾種來自Leader的消息：
Follower的工作流程簡圖如下所示，在實際實現中，Follower是通過5個線程來實現功能的。
https://blog.csdn.net/xinguan1267/article/details/38422149
https://blog.csdn.net/gs80140/article/details/51496925
https://www.2cto.com/kf/201708/668587.html
https://blog.csdn.net/milhua/article/details/78931672
P.S. 這篇文章是本人對網路上關於ZK的文章閱讀之後整理所得，作為入門級的了解。個人覺得看了上面的內容就能基本了解Zookeeper的作用了，後面在結合實際項目使用加深自己的了解。
end
❷ Zookeeper的腦裂問題及解決方案
先拋出一個問題：Zookeeper3.4.6版本是否存在腦裂問題？
一，什麼是腦裂
什麼是腦裂呢？
下圖是一個正常的Zookeeper集群，由7個節點組成。其中有1個Leader A和6個Follower。
當網路發送故障時，Follower D、Follower E、Follower F從集群中斷開了，然後這3個節點認為Leader掛了，然後重新選了1個Leader，Follower E變成了Leader B，如下圖，這就是腦裂。
上圖有可能存在一個問題，因為Zookeeper集群的一個特性是：過半節點存活可用。如何理解。網上有一個說法：有100個節點組成的集群，如果被網路分割成50和50兩個分區，那麼整個集群是不可用的，因為不滿足過半節點存活可用的原則。
二，Zookeeper3.4.6版本是否存在腦裂問題
首先，Zookeeper3.4.6不存在腦裂的問題。
為什麼呢？
Zookeeper3.4.6的選舉演算法是FastLeaderElection，該演算法的規則是投票超過半數的伺服器才能當選為Leader。這個演算法能夠保證leader的唯一性。
❸ 配置奇數個zookeeper 只起偶數個活的zookeeper 怎麼選舉leader
選舉機制(FastLeaderElection演算法)：sid最大且被超過集群中超過半數的機器擁護就會成為leader.
所以只有兩種情況無法選出leader：
整個集群只有2台伺服器（注意不是只剩2台，而是集群的總節點數為2）
整個集群超過半數機器掛掉。
所謂的偶數問題其實是另一個集群優化配置問題，即:集群的容災數量=集群總節點數/2-1
假如集群有5節點，那麼最多允許2個節點掛掉，如果有3節點掛了，那麼整個集群的選舉結果不會滿足條件：集群中超過半數的機器擁護。
假如集群有6個節點，那麼最多也只能掛掉2台，因為掛了3台時，選舉結果也不會滿足條件:集群中超過半數的機器擁護。
結果可以看出，多那一台用處並不大。所以集群總數推薦為奇數。