机制"/>
zookeeper 简介特点 功能 选举机制
目录
- Zookeeper简介
- Zookeeper选举机制
- 什么时候集群会进行Leader选举?
- 服务器初始化启动-选举机制
- Follower无法和Leader进行通信-选举机制
- Zookeeper 主要功能
Zookeeper简介
zk是一个分布式协调资源框架
,其中主要有3个角色
- Leader领导者:
- 处理事务请求(增删改)
- 资源协调
- Follower跟随者:
- 处理客户端非事务请求(查询),转发事务请求Leader服务器
- 参与Leader选举投票
- Observer观察者:
分担Follower压力(因为查询次数特别多)处理客户端非事务请求(查询),转发请求给Leader服务器
Zookeeper选举机制
什么时候集群会进行Leader选举?
- 服务器初始化启动时
- 服务器运行期间无法和Leader进行通信
服务器初始化启动-选举机制
选举状态:
LOOKING: 竞选状态
OBSERVING: 观察状态,同步 leader 状态,不参与投票
FOLLOWING: 随从状态,同步 leader 状态,参与投票
LEADING: 领导者状态
假设有五台服务器组成的Zookeeper集群,从Service1到Service5,同时它们都是第一次启动
,也就是没有历史数据。假设这些服务器依序启动,来看看会发生什么
-
Service1启动,发起一次选举。Service1投自己一票,此时Service1票数一票,不够半数以上(3票),选举无法完成,服务器1状态保持为LOOKING
-
Service2启动,发起一次选举。Service2投自己一票,并与Service1交换选票信息,此时Service1发现Service2的myid比自己大,将自己的选票给Service2。此时Service1票数0票,Service2票数2票,但仍没有达到半数以上,选举无法完成,Service1,Service2状态保持为LOOKING
-
Service3启动,发起一次选举。Service3投自己一票,并与其它服务器交换选票信息,因Service3的myid最大,Service2将自己的选票给Service3。此时Service1为0票,Service2为0票,Service3为3票。此时Service3的票数已经达到半数以上,Service3当选Leader。Service1与Service2更改状态为FOLLOWING,Service3更改状态为LEADING
-
Service4启动,发起一次选举。此时Service1,Service2,Service3已经不是LOOKING状态,不会更改选票信息。此时Service3为3票,Service4为1票,少数服从多数,Service4更改自己的状态为FOLLOWING
-
Service5和Service4同理,会将自己的状态为FOLLOWING
Follower无法和Leader进行通信-选举机制
- Follower挂掉了,但集群中仍存在Leader
Follower被修复后,仅需要和Leader机器尝试建立连接,然后进行状态同步即可
- Follower没挂,Leader挂掉了
先来了解以下3个概念
SID:
服务器ID,用来唯一标识一台ZooKeeper集群中的机器,每台机器不能重复,和myid一致
ZXID:
事务ID,在响应客户端请求时(增删改)值会被更新,值越大说明数据越新
Epoch:
逻辑时钟(epoch-logicalclock),没有Leader时,同一轮投票过程中的逻辑时钟值是相同的,每投完一次值会增加
假设ZooKeeper由5台服务器组成,SID分别为1、2、3、4、5,ZXID分别为8、8、8、7、7,并且此时SID3的服务器是Leader。某一时刻服务器SID3和SID5出现故障,因此开始进行Leader选举
SIDx->(EPOCH,ZXID,SID )
SID1->( 1, 8, 1)
SID2->( 1, 8, 2)
SID4->( 1, 7, 4)
选举Leader原则:
- EPOCH大的直接胜出
- EPOCH相同,ZXID大的胜出
- ZXID相同,SID大的胜出
故:SID2当选为Leader
Zookeeper 主要功能
- 统一命名服务
2. 统一配置管理
- 统一集群管理
- 服务器动态上下线
- 软负载均衡
更多推荐
zookeeper 简介特点 功能 选举机制
发布评论