Zookeeper自动选主

傷城~ 2022-05-12 05:48 161阅读 0赞

zookeeper，一个致力于分布式应用程序协调服务的框架。  
使用场景包括：  
1、配置中心  
2、命名服务（RPC的使用场景，Eureka也是个不错的选择）  
3、通知协调（基于zk的发布订阅功能）  
4、心跳检测  
5、Master选举（抢占式，类似redis的setnx，只能创建一个，创建成功的抢占成功）  
6、锁  
上面很多场景都是基于zk的watcher监听机制，当监听的节点发生变更会通知所有监听该节点的客户端，而通知则是基于zk的原子广播（基于Zab协议）。  
而ZAB协议有两种模式：  
1、广播模式，zk大部分时间处于广播模式。主要处理客户端请求和leader与Follow之间的状态同步。  
1、恢复模式，当系统启动或者leader节点down掉或者失去大部分Follow的时候进入恢复模式，进行选主流程。

**自动选主**  
了解这个过程，分四个步骤  
1、系统角色

<table> 
 <thead> 
  <tr> 
   <th>角色</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Leader</td> 
   <td>领导者，负责进行投票的发起和决议，更新系统状态</td> 
  </tr> 
  <tr> 
   <td>Follower</td> 
   <td>跟随者（学习者），用于接受客户端请求并发挥结果，在选中过程中参与投票</td> 
  </tr> 
  <tr> 
   <td>ObServer</td> 
   <td>观察者（学习者），要手动修改配置指定一个Server为观察者，可以接受请求，但是转发给leader处理，不参与投票，只同步状态，接受投票结果</td> 
  </tr> 
 </tbody> 
</table>

2、交互事件（选举过程中跟随者节点之间持续发生的事件）  
（1）发送消息给其他节点  
（2）接受其他节点发送过来的信息  
（3）处理其他节点发送过来的信息

3、消息内容  
（1）myid：来源节点想要推举的leaderid，和zxid用（myid，zxid表示）  
（2）id：来源节点的id（可以等于leaderid，即自己推举自己当leader）  
（3）zxid：来源节点当前数据版本，值越大则数据越新，这是成为leader最重要的条件  
（4）epoch：当前选举轮次标识（逻辑时钟），值越大则轮次越新，成为leader的首要条件。

4、选主过程  
（1）集群启动  
（2）集群每个服务节点都没有数据，数据版本都相等，即为默认值。  
（3）此时没有leader，每个节点都推举自己当leader，即id=myid，将以上四个信息广播给其他所有节点（包括自己）  
（4）接受到其他节点发送的信息的节点，先要判断来源节点状体，如果对方处于Looking，且自己处于Following或者leading则直接回复消息通知来源节点，leading已产生，请尽快同步。如果自己也处于looking状态，则对来源信息和自己的信息进行对比。1.对比epoch，采用值较大者的信息。2.如果epoch一样则对比zxid，采用值较大者的信息。3.如果zxid也一样，则比较节点id，采用值较大者的信息。如果采用的是来源节点的信息，则更新自己的节点信息，并且广播给其他节点。否则直接将自己的信息直接广播给其他节点。  
（5）直到某轮选举已经选出被绝大多数节点承认的leader，其他节点同步新leader的状态。