您的位置: 首页  >  文章  >  zookeeper(三)

zookeeper(三)

分类: 文章 • 2025-02-01 19:59:22

zookeeper集群角色

leader

  1. 事务请求的唯一调度者和处理者，保证集群事务处理的顺序性
  2. 集群内部各个服务器的调度者

follower

  1. 处理客户端非事务请求，以及转发事务请求给leader服务器
  2. 参与事务请求提议（proposal）的投票（客户端的一个事务请求，需要半数服务器投票通过以后才能通知leader commit； leader会发起一个提案，要求follower投票）
  3. 参与leader选举的投票

observer

观察zookeeper集群中最新状态的变化并将这些状态同步到observer服务器上增加observer不影响集群中事务处理能力，同时还能提升集群的非事务处理能力
zookeeper的集群组成
zookeeper一般是由 2n+1台服务器组成

leader选举

leaderElection/AuthFastLeaderElection/FastLeaderElection
QuorumPeer startLeaderElection

zookeeper·默认选举方式

FastLeaderElection

serverid : 在配置server集群的时候，给定服务器的标识id（myid）
zxid : 服务器在运行时产生的数据ID， zxid的值越大，表示数据越新
Epoch: 选举的轮数
server的状态：Looking、 Following、Observering、Leading

zookeeper选举流程

zookeeper(三)
一、首先开始选举阶段，每个Server读取自身的zxid。

二、发送投票信息

a、首先，每个Server第一轮都会投票给自己。

b、投票信息包含 ：所选举leader的Serverid，Zxid，Epoch。Epoch会随着选举轮数的增加而递增。

三、接收投票信息

1、如果服务器B接收到服务器A的数据（服务器A处于选举状态(LOOKING 状态)

首先，判断逻辑时钟值：

a）如果发送过来的逻辑时钟Epoch大于目前的逻辑时钟。首先，更新本逻辑时钟Epoch，同时清空本轮逻辑时钟收集到的来自其他server的选举数据。然后，判断是否需要更新当前自己的选举leader Serverid。判断规则rules judging：保存的zxid最大值和leader Serverid来进行判断的。先看数据zxid,数据zxid大者胜出;其次再判断leader Serverid,leader Serverid大者胜出；然后再将自身最新的选举结果(也就是上面提到的三种数据（leader Serverid，Zxid，Epoch）广播给其他server)

b）如果发送过来的逻辑时钟Epoch小于目前的逻辑时钟。说明对方server在一个相对较早的Epoch中，这里只需要将本机的三种数据（leader Serverid，Zxid，Epoch）发送过去就行。

c）如果发送过来的逻辑时钟Epoch等于目前的逻辑时钟。再根据上述判断规则rules judging来选举leader ，然后再将自身最新的选举结果(也就是上面提到的三种数据（leader Serverid，Zxid，Epoch）广播给其他server)。

其次，判断服务器是不是已经收集到了所有服务器的选举状态：若是，根据选举结果设置自己的角色(FOLLOWING还是LEADER)，退出选举过程就是了。

最后，若没有收到没有收集到所有服务器的选举状态：也可以判断一下根据以上过程之后最新的选举leader是不是得到了超过半数以上服务器的支持,如果是,那么尝试在200ms内接收一下数据,如果没有新的数据到来,说明大家都已经默认了这个结果,同样也设置角色退出选举过程。

2、 如果所接收服务器A处在其它状态（FOLLOWING或者LEADING）。

a)逻辑时钟Epoch等于目前的逻辑时钟，将该数据保存到recvset。此时Server已经处于LEADING状态，说明此时这个server已经投票选出结果。若此时这个接收服务器宣称自己是leader, 那么将判断是不是有半数以上的服务器选举它，如果是则设置选举状态退出选举过程。
　　　　b) 否则这是一条与当前逻辑时钟不符合的消息，那么说明在另一个选举过程中已经有了选举结果，于是将该选举结果加入到outofelection集合中，再根据outofelection来判断是否可以结束选举,如果可以也是保存逻辑时钟，设置选举状态，退出选举过程。

ZAB协议

paxos协议主要就是如何保证在分布式环网络环境下，各个服务器如何达成一致最终保证数据的一致性问题

ZAB协议，基于paxos协议的一个改进。zab协议为分布式协调服务zookeeper专门设计的一种支持崩溃恢复的原子广播协议，zookeeper并没有完全采用paxos算法， 而是采用zab Zookeeper atomic broadcast。

zab协议的原理

  1. 在zookeeper 的主备模式下，通过zab协议来保证集群中各个副本数据的一致性
  2. zookeeper使用的是单一的主进程来接收并处理所有的事务请求，并采用zab协议，把数据的状态变更以事务请求的形式广播到其他的节点
  3. zab协议在主备模型架构中，保证了同一时刻只能有一个主进程来广播服务器的状态变更
  4. 所有的事务请求必须由全局唯一的服务器来协调处理，这个的服务器叫leader，其他的叫follower，leader节点主要负责把客户端的事务请求转化成一个事务提议（proposal），并分发给集群中的所有follower节点，再等待所有follower节点的反馈。一旦超过半数服务器进行了正确的反馈，那么leader就会commit这条消息

崩溃恢复
原子广播

zab协议的工作原理

什么情况下zab协议会进入崩溃恢复模式

  1. 当服务器启动时
  2. 当leader服务器出现网络中断、崩溃或者重启的情况
  3. 集群中已经不存在过半的服务器与该leader保持正常通信

zab协议进入崩溃恢复模式会做什么

  1. 当leader出现问题，zab协议进入崩溃恢复模式，并且选举出新的leader。当新的leader选举出来以后，如果集群中已经有过半机器完成了leader服务器的状态同（数据同步），退出崩溃恢复，进入消息广播模式
  2. 当新的机器加入到集群中的时候，如果已经存在leader服务器，那么新加入的服务器就会自觉进入数据恢复模式，找到leader进行数据同步

https://www.cnblogs.com/shuaiandjun/p/9383655.html

相关推荐