-
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