一、概述
1、集羣中的角色
- Leader
Zookeeper集羣工作的核心，事務請求（寫操作）唯一調度和處理者，保證集羣事務處理的順序性；集羣內部各個服務的調度者。對於 create、setData、delete等有些操作的請求，則需要統一轉發給Leader處理，Leader需要決定編號、執行操作，這個過程稱為一個事務。 - Follower
處理客户端非事務（讀操作）請求，轉發事務請求給Leader, 參與Leader選取投票。 - Observer
觀察者角色，觀察zookeeper集羣的最新狀態變化並將狀態同步過來，其對於非事務的請求可以進行獨立處理，對於事務請求，則會轉發給Leader服務器處理，不會參數任何形式的投票只提供服務，其實就是增加非事務的併發量。
2、集羣為什麼要搭建奇數個節點
- 如果部署單個節點，當節點宕機時，集羣就會失效，就會出現單點故障。
- 如果部署兩個節點，2的半數為1，半數以上最少為2，不允許有一台機器故障，不然投票機制不成立。
- 如果部署三個節點，3的半數為1.5，半數以上最少為2，允許有一台機器故障，投票機制可以成立。
- 如果部署四個節點，4的半數為2，半數以上最少為3，允許有一台機器機器故障，投票機制可以成立。
- 如果部署五個節點，5的半數為2.5，半數以上最少為3，允許有兩台機器故障，投票機制可以成立。
- 所以部署zookeeper集羣的時候一般部署的節點數量為
2n+1台節點。
二、集羣選取機制
1、節點狀態
| 名稱 | 描述 |
|---|---|
| Looking | 這個是在選舉的過程中的狀態，正在選舉。 |
| Leading | 領導者狀態，説明當前節點角色已經是Leader。 |
| Following | 跟隨者狀態，表示選舉已經完成，當前角色已經是Following。 |
| Oberver | 觀察者狀態，表示當前節點角色是observer。 |
2、事務ID
Zookeeper狀態每次變化都接收一個ZXID（zookeeper事務id）形式的標記，由Leader統一分配，全局唯一，不斷遞增。
3、初始化選取過程
由三個節點舉例：當第一個節點啓動的時候，因為單節點無法進行選舉，所以當第二個節點啓動之後，兩台機器之間可以互相通信了，開始選舉過程：
- 1、兩個節點都當自己是 Leader 角色來投票，每次投票都包含服務器配置的
myid（下文中能找到myid）中的值和ZXID。使用(myid, zxid)表示，此時第一個節點為(1, 0)，第二個節點為(2, 0)，然後將自己的值發給其他節點。 - 2、當其他服務收到投票後，先判斷是否是本輪投票，投票的機器的狀態是否為
Looking。 - 3、針對每次的投票，服務器都需要將自己的票數和其他服務器對比。先檢查
ZXID，這個時候ZXID都為0，如果ZXID誰的大誰就是Leader，如果ZXID相同就對比myid，第二個節點的myid為2，所以第二個節點就是Leader。 - 4、每次投票之後，服務器會統計是否有過半的機器接收到相同的投票信息，如果已經過半，就確認第二個節點為 Leader。
- 5、一旦確認了 Leader，每台服務器都會更新自己的狀態。如果是
Follower角色，就改變狀態為Following，如果是Leader角色，就改變狀態為Leading。當第三個節點進來的發現已經有了 Leader, 狀態直接變成Following。
4、運行狀態下選舉
以下當第二個節點故障，第一個節點和第三個節點是良好的節點。
- 1、當 Leader 掛掉之後，集羣會拒絕所有的服務，餘下非
Observer服務器都會將自己的服務器的狀態變更為Looking。然後開始選舉。 - 2、每個節點會發出投票。運行期間，節點上的
ZXID可能不同，假設：第一個節點的ZXID為100，第三個節點的ZXID為120，這個時候第一個節點和第三個節點都會投票自己，第一個節點為(1, 100)，第三個節點為(3, 120)，由於第三個節點的ZXID為120，直接選舉為 Leader。 - 3、其他步驟和初始化啓動的時候一樣。
