zookeeper 简介特点 功能 选举机制

机制"/>

zookeeper 简介特点 功能 选举机制

目录

• • Zookeeper简介
  • Zookeeper选举机制
  • • 什么时候集群会进行Leader选举？
    • 服务器初始化启动-选举机制
    • Follower无法和Leader进行通信-选举机制
  • Zookeeper 主要功能

Zookeeper简介

zk是一个分布式协调资源框架，其中主要有3个角色

• Leader领导者：

1. 处理事务请求（增删改）
2. 资源协调

• Follower跟随者：

1. 处理客户端非事务请求（查询），转发事务请求Leader服务器
2. 参与Leader选举投票

• Observer观察者：

分担Follower压力（因为查询次数特别多）处理客户端非事务请求（查询），转发请求给Leader服务器

Zookeeper选举机制

什么时候集群会进行Leader选举？

1. 服务器初始化启动时
2. 服务器运行期间无法和Leader进行通信

服务器初始化启动-选举机制

选举状态：

LOOKING: 竞选状态
OBSERVING: 观察状态，同步 leader 状态，不参与投票
FOLLOWING: 随从状态，同步 leader 状态，参与投票
LEADING: 领导者状态

假设有五台服务器组成的Zookeeper集群，从Service1到Service5，同时它们都是第一次启动，也就是没有历史数据。假设这些服务器依序启动，来看看会发生什么

1. Service1启动，发起一次选举。Service1投自己一票，此时Service1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为LOOKING

2. Service2启动，发起一次选举。Service2投自己一票，并与Service1交换选票信息，此时Service1发现Service2的myid比自己大，将自己的选票给Service2。此时Service1票数0票，Service2票数2票，但仍没有达到半数以上，选举无法完成，Service1，Service2状态保持为LOOKING

3. Service3启动，发起一次选举。Service3投自己一票，并与其它服务器交换选票信息，因Service3的myid最大，Service2将自己的选票给Service3。此时Service1为0票，Service2为0票，Service3为3票。此时Service3的票数已经达到半数以上，Service3当选Leader。Service1与Service2更改状态为FOLLOWING，Service3更改状态为LEADING

4. Service4启动，发起一次选举。此时Service1，Service2，Service3已经不是LOOKING状态，不会更改选票信息。此时Service3为3票，Service4为1票，少数服从多数，Service4更改自己的状态为FOLLOWING

5. Service5和Service4同理，会将自己的状态为FOLLOWING

Follower无法和Leader进行通信-选举机制

1. Follower挂掉了，但集群中仍存在Leader

Follower被修复后，仅需要和Leader机器尝试建立连接，然后进行状态同步即可

2. 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原则:

1. EPOCH大的直接胜出
2. EPOCH相同，ZXID大的胜出
3. ZXID相同，SID大的胜出

故：SID2当选为Leader

Zookeeper 主要功能

1. 统一命名服务

2. 统一配置管理

3. 统一集群管理

4. 服务器动态上下线

5. 软负载均衡