ZAB协议-zk

我会带着你远行 2021-08-19 16:04 388阅读 0赞

参考文章：  
https://blog.csdn.net/chengyuqiang/article/details/79190061  
https://blog.csdn.net/wangyangzhizhou/article/details/52698555  
https://blog.csdn.net/yangguosb/article/details/80254240

ZK中使用的是ZAB协议，ZAB（ZooKeeper Atomic Broadcast ）全称为：原子消息广播协议，作为数据一致性的算法，ZAB在Paxos算法基础上进行了扩展改造，ZAB协议设计了支持崩溃恢复，ZooKeeper使用单一主进程Leader用于处理客户端所有事务请求，采用ZAB协议将服务器数状态以事务形式广播到所有Follower上；

关于ZAB协议：https://blog.csdn.net/wangyangzhizhou/article/details/52698555

ZAB的三种协议状态：

![70][]

**ZAB****的几个阶段：**

![70 1][]

**重点关注选举阶段：**

**（包括初始化阶段的选举和leader****崩溃时的重新选举）**

[**https://blog.csdn.net/chengyuqiang/article/details/79190061**][https_blog.csdn.net_chengyuqiang_article_details_79190061]

![70 2][]

![70 3][]

**关于zxid****：**

[**https://blog.csdn.net/yangguosb/article/details/80254240**][https_blog.csdn.net_yangguosb_article_details_80254240]

![70 4][]

![70 5][]

**选举leader****时根据zxid****，zxid****大就作为leader****，相同就比较myid****。**

**选举完leader****后，把所有参与选举的server****的zxid****的epoch****变为epoch****最大的那个server****（leader****的）+1****（表示进入新的一轮leader****周期），后32****位置为0.**

Zxid（事务编号）是存储在本地的，每个zkserver都有自己的zxid，zixd是个64位的数字，前32位epoch表示leader的周期（比如为5表示这是第五次leader选举），后32位是计数器，客户端发出一个请求给leader（每个请求都是个事务），leader把请求发给集群中所有flower，flower对事务处理后，计数器就加一。Leader的zxid一定是最大的，因为客户端请求先找它，它的事务日志是最新的，将来follower找它去做数据同步。

每次启动zk的server进行选举时，会从本地加载zxid，来进行大小比较，选举出新的leader后将epoch+1（**假如flower的上次周期比leader小，这次选举后会更新成leader的周期，表示在同一个周期**），表示新的一个leader周期，同时将计数器置为0。

比如三台zk服务器，初始化它们的zxid一样的，myid依次为1 2 3

假如我先启动zk1，再启动zk2，这时因为zk1的zxid和zk2的相同都为0，这时根据myid，zk2作为leader，再启动zk3，因为已经有leader，所以zk3为flower。这时它们的zxid的epoch都+1，新的一轮leader。假设都处理了n个客户端事务，计数器都为n.所以zxid都为\[1,n\],\[1,n\],\[1,n\]. 前32位后32位。

第二次我只启动zk1和zk3，这时因为zxid相同，zk3的myid大，zk3为leader。

选出leader后它们的zxid都为2,0 （leader的周期+1，计数器置0），这时停掉服务器。

第三次我启动zk1和zk2，因为zk1的zxid为2,0 zk2为1，n 所以zk1大，zk1为leader，而不是zk2。

**注意：这时将zk1****的zxid****为3,0****，zk2****为3,0****。只要在选举出leader****后，要更新leader****和flower****的epoch****相同，即它们要处于同一个leader****周期中！也就是会把本地最大的zxid****（zk1****的）的epoch+1****作为新的epoch****。**

下次假设再启动zk1和zk2，zk2就会为leader。

**Zk****给服务器选举master****：**

选主原理介绍：zookeeper的节点有两种类型，持久节点跟临时节点。临时节点有个特性，就是如果注册这个节点的机器失去连接(通常是宕机)，那么这个节点会被zookeeper删除。选主过程就是利用这个特性，在服务器启动的时候，去zookeeper特定的一个目录下注册一个临时节点(这个节点作为master，谁注册了这个节点谁就是master)，注册的时候，如果发现该节点已经存在，则说明已经有别的服务器注册了(也就是有别的服务器已经抢主成功)，那么当前服务器只能放弃抢主，作为从机存在。同时，抢主失败的当前服务器需要订阅该临时节点的删除事件，以便该节点删除时(也就是注册该节点的服务器宕机了或者网络断了之类的)进行再次抢主操作。从机具体需要去哪里注册服务器列表的临时节点，节点保存什么信息，根据具体的业务不同自行约定。选主的过程，其实就是简单的争抢在zookeeper注册临时节点的操作，谁注册了约定的临时节点，谁就是master。

**为什么是奇数个节点？**

因为容忍能力一样，即挂掉的节点数是一样的，奇数个更加节约。

![70 6][]

**大数据生态圈中还有其他的选举协议吗**

Paxos算法：一般基于消息传递的一致性算法的选举协议都是基于它的。

[70]: /images/20210527/8246d0c80f824941832d924115c14f89.png
[70 1]: /images/20210527/65930ffc47044c72b7c356367a88770f.png
[https_blog.csdn.net_chengyuqiang_article_details_79190061]: https://blog.csdn.net/chengyuqiang/article/details/79190061
[70 2]: /images/20210527/91c90b41ce0345ebb1439b02707e0b14.png
[70 3]: /images/20210527/369b4b7447494806a2f19eb6b4e69cc7.png
[https_blog.csdn.net_yangguosb_article_details_80254240]: https://blog.csdn.net/yangguosb/article/details/80254240
[70 4]: /images/20210527/4e0b3f4d1906498b902d00d4c277e246.png
[70 5]: /images/20210527/b9a1306e120c4dc48314a537753a561d.png
[70 6]: /images/20210527/2fe7a4bcc1ba4247b3a14375ea3c9c7e.png