-
Dubbo應用為什么要部署Zookeeper?
Zookeeper用來注冊和發現服務，簡單說就是提供端注冊接口信息到Zookeeper，調用端在Zookeeper上查找接口對應的服務IP和端口。由於Zookeeper集群的高可用性，Dubbo推薦采用Zookeeper作為服務治理的基礎組件。 -
Zookeeper怎么做到高可用的？
ZooKeeper集群解決了單點和容災的問題，滿足CAP理論中的CP特性，即一致性和分區容錯性。ZooKeeper集群基於過半設計原則，至少有過半的機器保存了最新的數據，只要超過半數的機器正常工作，整個集群就能夠對外提供服務。集群有leader、follower、observer三種角色，當leader宕機時，follower選舉出新的leader繼續提供服務。 -
解釋一下Zookeeper過半原則？
集群中半數以上的機器處於可用狀態，它就能夠提供服務。例如在一個有5個節點的集群中，每個Follower節點的數據都是Leader節點數據的副本，每個節點的數據視圖都是一樣的。任意2台機器出現故障，都可以保證繼續服務，剩下的3台機器超過了半數。6個節點的集群也只能夠容忍2台機器出現故障，如果3台機器出現故障，剩下的3台沒有超過集群的半數。所以建議集群里搭建奇數個節點。 -
那你說說leader的選舉機制
- 選舉階段 Leader election
最大ZXID也就是節點本地的最新事務編號，包含epoch和計數兩部分。epoch是紀元的意思，相當於Raft算法選主時候的term，標識當前leader周期，每次選舉一個新的Leader服務器后，會生成一個新的epoch。
所有節點處於Looking狀態，各自依次發起投票，投票包含自己的服務器ID和最新事務ID（ZXID）。
如果發現別人的 ZXID比自己大，也就是數據比自己新，那么就重新發起投票，投票給目前已知最大的 ZXID所屬節點。
每次投票后，服務器都會統計投票數量，判斷是否有某個節點得到半數以上的投票。如果存在這樣的節點，該節點將會成為准Leader，狀態變為 Leading，其他節點的狀態變為Following。 - 發現階段 Discovery
為了防止某些意外情況，比如因網絡原因在上一階段產生多個Leader的情況。Leader集思廣益，接收所有 Follower發來各自的最新 epoch值。Leader從中選出最大的 epoch，基於此值加1，生成新的 epoch分發給各個 Follower。
各個 Follower收到全新的epoch后，返回ACK給Leader，帶上各自最大的ZXID和歷史事務日志。 Leader選出最大的ZXID，並更新自身歷史日志。 - 同步階段 Synchronization
Leader剛才收集得到的最新歷史事務日志，同步給集群中所有的Follower。只有當半數Follower同步成功，這個准Leader才能成為正式的Leader。
- 選舉階段 Leader election
-
什么情況下觸發選舉呢？
- 集群剛剛啟動的時候
- 服務器處於尋找Leader狀態
- 當服務器處於LOOKING狀態時，表示當前沒有Leader，需要進入選舉流程
- Leader宕機
- 網絡原因導致過半節點與Leader心跳中斷
-
Zookeeper有什么缺點？
- zookeeper的選舉流程通常耗時30到120秒，由於沒有master，選舉期間都是不可用的。
- zookeeper的性能是有限的，典型的zookeeper的TPS大概是一萬多。
- zookeeper的權限控制非常薄弱。
參考(部分摘抄的文字版權屬於原作者)：
https://www.cnblogs.com/shuaiandjun/p/9383655.html
https://blog.csdn.net/liuhaiabc/article/details/70771322
https://blog.51cto.com/13550113/2318147
https://blog.csdn.net/qqqq0199181/article/details/80865828
https://www.cnblogs.com/AndyAo/p/8299317.html
https://www.jianshu.com/p/57fecbe70540
https://www.jianshu.com/p/26f73fe23b79
https://blog.51cto.com/welcomeweb/2103292?utm_source=oschina-app