Zookeeper集群选举机制以及数据同步机制

雨点打透心脏的1/2处 2023-08-17 17:30 71阅读 0赞

## Zookeeper集群选举机制以及数据同步机制 ##

每天多学一点点~  
话不多说，这就开始吧…进击的爆裂无球~

### 文章目录 ###

*   *  Zookeeper集群选举机制以及数据同步机制
     *  1.前文
     *  2.Zookeeper的选举机制
     *  3.Zookeeper的数据同步机制
     *  4.关于Zookeeper的一些面试题
     *  5.结语

## 1.前文 ##

国庆快乐，举国同庆~  
之前写过[zookeeper的集群搭建][zookeeper]以及  
[Zookeeper的选举及运维可视化查看器及容灾][Zookeeper]，因有点时间没用Zookeeper，最近又深入学习了一下，研究研究它的选举机制和数据同步机制，以便以后复习用~

## 2.Zookeeper的选举机制 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQzNzYzMw_size_16_color_FFFFFF_t_70]  
**投票机制说明：**  
选举分5个步骤：

1.  初始化leader选举，投票  
    给自己投票 myid zxid 0
2.  每个服务器接受投票  
    (1 0) (2,0) (3,0) >myid 谁最大谁就是leader
3.  处理投票  
    别的服务器 pk
4.  统计投票
5.  过半票数n=n/2+1;  
    服务器状态变更  
    Leader，其他票数低 f

依次启动三个zk，发现192.168.73.132是leader，其余两个是follower，这是因为  
1: 三个服务器的myid分别是 1 2 3  
2: 满足过半统计，即一共三个，启动第二个时候已经满足过半，所以第二个自动是leader  
**若反过来启动，即 按照 133-132-131的顺序，则133是leader，因为 133的myid最大，且启动132时候已经满足过半，所以133是leader**

**选举触发：**  
那么何时才会触发选举呢？

1.  服务节点初始化启动
2.  半数以上的节点无法和Leader建立连接

当节点初始起动时会在集群中寻找Leader节点，如果找到则与Leader建立连接，其自身状态变化follower或observer。如果没有找到Leader，当前节点状态将变化LOOKING，进入选举流程。  
在集群运行其间如果有follower或observer节点宕机**只要不超过半数**并不会影响整个集群服务的正常运行。但如果leader宕机，**将暂停对外服务**，所有follower将进入LOOKING 状态，进入选举流程。

## 3.Zookeeper的数据同步机制 ##

Zookeeper 的数据同步是为了保证各节点中数据的一致性，同步时涉及两个流程，一个是正常的客户端数据提交，另一个是集群某个节点宕机在恢复后的数据同步。

*  **客户端写入请求**：  
    写入请求的大至流程是，收leader接收客户端写请求，并同步给各个子节点。如下图：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQzNzYzMw_size_16_color_FFFFFF_t_70 1]  
    但实际情况要复杂的多，比如 **client 它并不知道哪个节点是leader** ，有可能写的请求会发给follower ，由follower在转发给leader进行同步处理  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQzNzYzMw_size_16_color_FFFFFF_t_70 2]  
    客户端写入流程说明：

1.  client向zk中的server发送写请求，如果该server不是leader，则会将该写请求转发给leader server，leader将请求事务以proposal形式分发给follower；
2.  当follower收到收到leader的proposal时，根据接收的先后顺序处理proposal；
3.  当Leader收到follower针对某个proposal过半的ack后，则发起事务提交，重新发起一个commit的proposal
4.  Follower收到commit的proposal后，记录事务提交，并把数据更新到内存数据库；
5.  当写成功后，反馈给client。

*  **服务节点初始化同步**：  
    在集群运行过程当中如果有一个follower节点宕机，由于宕机节点没过半，**集群仍然能正常服务**。当leader 收到新的客户端请求，此时无法同步给宕机的节点。造成数据不一致。为了解决这个问题，当节点启动时，第一件事情就是找当前的Leader，比对数据是否一致。不一致则开始同步,同步完成之后在进行对外提供服务。  
    如何比对Leader的数据版本呢，这里通过**ZXID(事物ID)来确认。比Leader就需要同步。  
    ZXID说明：  
    ZXID是一个长度64位的数字，其中低32位是按照数字递增**，任何数据的变更都会导致,低32位的数字简单加1。**高32位是leader周期编号**，每当选举出一个新的leader时，新的leader就从本地事物日志中取出ZXID,然后解析出高32位的周期编号，进行加1，再将低32位的全部设置为0。这样就保证了每次新选举的leader后，保证了ZXID的唯一性而且是保证递增的。  
    可以用运维四字命令查看，之前文章中也说过  
    echo stat|nc 127.0.0.1:2181  
    比如 ：0x200000002 是当前的zxid，当leader变化时，高32变化，变成0x3 ，+1  
    当数据变化时候，低32变化 +1 变成00000003

## 4.关于Zookeeper的一些面试题 ##

1.  如果leader 节点宕机，在恢复后它还能被选为leader吗？  
    **不能**，因为会重新选举(**选举期间暂停对外服务，直到新的leader产生**)，然后再次加进来，原来的leader会跟新的leader进行数据同步，变成follwer
2.  现在有三个节点， zk1,zk2,zk3， zk2是leader，zk2挂了的同时在zk1进行了delete操作，现在把zk1 和 zk3也挂掉，再把三个节点全部起来，那么现在zk2还是leader嘛？  
    **不是**。 因为你leader挂了之后，就会选举出新的leader(zk3)，此时你在zk1中更新的数据（delete了一条数据）此时zk1和zk3的zxid是一致的，已经同步呢！  
    (你老的leader(zk2)中的数据不是最新的，怎么好意思再给follower同步数据呢！)  
    现在你又把zk1和zk3挂掉，再重启zk1,zk2,zk3，此时的选举，**不再是一开始根据myid谁大谁就是leader**，而**是基于zxid(节点的事物ID)谁大谁就是leader**，因为zk1更新了数据，此时它的zxid是最大的，所以启动后zk1是leader  
    **最后集群状态一致的话，整个集群的zxid都会一样**

## 5.结语 ##

**世上无难事，只怕有心人，每天积累一点点，fighting！！！**

[zookeeper]: https://blog.csdn.net/weixin_42437633/article/details/88650473#8_75
[Zookeeper]: https://blog.csdn.net/weixin_42437633/article/details/88879075#1Zookeeper_4
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQzNzYzMw_size_16_color_FFFFFF_t_70]: /images/20230808/9d936488070d4ab880de0a770a74fbf1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQzNzYzMw_size_16_color_FFFFFF_t_70 1]: /images/20230808/bee69b0046954f1eb13c6a165ce9a412.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjQzNzYzMw_size_16_color_FFFFFF_t_70 2]: /images/20230808/9d18e480aa4844d084e2051079bf50de.png