微服务：5-zookeeper 选举机制

最新推荐文章于 2024-03-15 10:00:00 发布

rong742954

最新推荐文章于 2024-03-15 10:00:00 发布

阅读量208

点赞数

分类专栏：微服务文章标签：分布式 zookeeper 微服务 hdfs

本文链接：https://blog.csdn.net/qq_34220643/article/details/112789405

版权

12 篇文章 0 订阅

订阅专栏

leader 整个集群zk写请求的唯一处理者，并负责进行投票的发起和决议，更新系统状态
follower 接收客户端请求，处理读请求，并向客户端返回结果；将写请求转给Leader；在选举Leader过程参与投票
observer 无选举投票权的follower，主要协助follower处理更多的读请求
- 如果集群的读请求负载很高，或者客户端非常多，多到跨机房，则可以设置一些Observer服务器，以提高读取的吞吐量

zk的核心是广播机制，保证各个zk之间数据同步,zk实现的机制为ZAB协议
恢复模式: 如果Leader崩溃，这个时候就会进入恢复模式，使整个zk集群恢复到正常的工作状态
同步模式: 新的Leader选举出来后，就进入同步模式(各个follower会去同步新的Leader上的数据)，当大多数zkServer完成了与Leader状态同步后，恢复模式就结束
广播模式：客户端想写入数据，整个时候Leader发起提议，当Leader的提议被大多数的zkServer统一之后，Leader就会去修改自身的数据，并将修改后的数据广播给
其他的follower

myid

服务器唯一标识，如有三个zk服务器，编号分别： 1，2，3
zxid

ReentranReaderWriteLock 32位
- zxid位long类型，高32位epoch,低32位表示xid，即zxid由两部分构成
- 每个Leader都会具有个不同的epoch值，表示一个时期、时代。新的Leader产生，则会更新所有
  的zkServer的zxid中的epoch。
- 而xid为zk的事务id，每个写操作都是一个事务，都会有个xid。
- 每个写操作都需要由Leader发起一个提议，由所有Follower表决是否同意本次写操作
逻辑时钟

一个整型数，在选举时成为logical lock。在zxid中则为epoch值。
epoch与logical lock是同一个值，在不同情况下的不同名称。
zk的选举状态

LOOKING: 选举状态(查找Leader的状态)
LEADING: 领导者状态,处于该状态的服务器称为Leader
FOLLOWING: 随从状态，同步leader状态，处于该状态的服务器称为Flollower
OBSERVING: 观察状态，同步leader状态，处于该状态的服务器称为Observer

发生时机：整个集群群龙无首的时候
- 服务启动
- leader宕机之后
选举机制
- 集群中，半数zkServer同意，则产生新的leader
- 搭建集群时，一般是奇数个，半数以上同意产生leader
  三台服务器，最多允许一台宕机
  四台服务器，也是最多允许一台宕机

选举算法

如：

服务启动：有三台myid = 1,2,3

  myid=1 启动后，给自己投票，发布投票结果(myid,zxid)
  myid=2 启动，同样给自己投票，跟第一台比较，zxid一样，则比较myid，谁大，谁胜出

宕机时

  若leader宕机，此时活着的server将会修改状态为looking
  哪个服务的zxid比较大，则胜出leader