像Mysql的主從模式會分master主節點和slave從節點一樣，在zookeeper集群中，節點也有不同的角色，承擔着不同角色。
zookeeper有三種角色：老大Leader(領導者） 2、老二Follower （跟隨者） 3、老三Observer（觀察者）。其中，Follower和Observer歸類為Learner（學習者）
按重要性排序是Leader > Follower > Observer
老大領導者Leader
Leader在集群中只有一個節點，可以說是老大No.1，是zookeeper集群的中心，負責協調集群中的其他節點。從性能的角度考慮，leader可以選擇不接受客戶端的連接。
主要作用有：
1、發起與提交寫請求。
所有的跟隨者Follower與觀察者Observer節點的寫請求都會轉交給領導者Leader執行。Leader接受到一個寫請求后，首先會發送給所有的Follower，統計Follower寫入成功的數量。當有超過半數的Follower寫入成功后，Leader就會認為這個寫請求提交成功，通知所有的Follower commit這個寫操作，保證事后哪怕是集群崩潰恢復或者重啟，這個寫操作也不會丟失。
2、與learner保持心跳
3、崩潰恢復時負責恢復數據以及同步數據到Learner
老二跟隨者Follower
Follow在集群中有多個，主要的作用有：
1、與老大Leader保持心跳連接
2、當Leader掛了的時候，經過投票后成為新的leader。leader的重新選舉是由老二Follower們內部投票決定的。
3、向leader發送消息與請求
4、處理leader發來的消息與請求
老三觀察者Observer
可以說Observer是zookeeper集群中最邊緣的存在。Observer的主要作用是提高zookeeper集群的讀性能。通過leader的介紹我們知道zookeeper的一個寫操作是要經過半數以上的Follower確認才能夠寫成功的。那么當zookeeper集群中的節點越多時，zookeeper的寫性能就 越差。為了在提高zookeeper讀性能（也就是支持更多的客戶端連接）的同時又不影響zookeeper的寫性能，zookeeper集群多了一個兒子Observer，只負責：
1、與leader同步數據
2、不參與leader選舉，沒有投票權。也不參與寫操作的提議過程。
3、數據沒有事務化到硬盤。即Observer只會把數據加載到內存。
下圖是zookeeper官方文檔中不同節點的zookeeper集群的性能表現（節點角色只有leader和follower）：
豎軸是每秒請求量，橫軸是讀請求的占比，不同顏色的曲線代表了不同數量的zookeeper節點，分別是3個節點，5個節點，7個節點，9個節點，13個節點。
可以看到，隨着讀請求所占的比例越來越多，zookeeper所能處理的請求數量是指數級得提升。除了三個節點的zookeeper集群外，當讀請求占比達到100%時，從曲線上看其他數量的集群能夠處理的請求幾乎無窮大。
當讀請求達到80%時，由於follower數量的增大導致寫請求的耗時增長，節點數量越多的zookeeper吞吐量越小（三個節點的集群是個例外）。吞吐量排序是：5>7>3>9>13。
正常情況下所有的請求都是讀請求是不可能的，肯定含有寫請求。所以建議zookeeper集群的讀寫比例為7:3或8:2最好，機器數量為5或者7台，不僅成本低也有良好的性能表現。
原文鏈接：https://blog.csdn.net/lamfang/article/details/109039288