ZooKeeper与ZAB一致性算法

• 简述ZAB协议以及ZooKeeper?
• 简述Paxos算法
• ZooKeeper的某个机器挂了，整个集群如何处理？
• 简述ZooKeeper的fastleaderelection选举leader的算法。
• ZooKeeper如何保证数据的一致性？
• ZooKeeper的监听原理?

ZooKeeper工作机制及其特点

1.简述ZAB协议以及ZooKeeper?

Zookeeper是一个高可用强一致的分布式协调服务，基于ZAB协议实现了一个主从一致的架构模式来保证数据的一致性。

zookeeper = 文件系统 + 通知机制

Zookeeper是一个基于主从一致的高可用集群，他的节点主要有几种角色：Leader、Follower、Observer

-Leader：一个集群只有一个Leader，负责写数据，处理数据同步的主节点，所有的数据写入必须先通过Leader再广播同步到所有的Follower

• Follower：负责存储数据，负责数据的读操作的节点。
• Observer：角色与Follower类似，但是无投票权，负责与用户对接，将请求转发给Leader。

ZAB协议全称为：（Zookeeper Atomic Broadcast ）Zookeeper原子广播协议

ZAB主要有两种模式：崩溃恢复模式、协议广播模式

• 崩溃恢复模式：在Zookeeper集群服务刚启动，和Leader挂掉的时候，就会启动崩溃恢复模式，主要是用于选出Leader。
• 协议广播模式：在有Leader的情况，就处于协议广播模式，所有的写入操作都经过Leader，并以类似二阶段提交的方式，写到Follower中去，在此过程中，Leader需要是不是接收来自Follower的心跳，若没有检测到来自超过半数的Follower心跳，或者TCP连接短开了，当前Leader放弃对当前周期的领导，Follower与Leader都进入Looking状态。

进一步可以细分三个阶段：

• 发现（Discovery）：投票竞选Leader过程
• 同步（Synchronization）（容易遗漏的点）：Leader刚上任，需要把自己节点上的数据同步到所有的Follower
• 广播（Broadcast）：服务开发，写入新的数据到Follower

2. 简述Paxos算法

Paxos算法是模拟了一个希腊城邦的提案的算法，一种是Basic Paxos，另一种是Multi Paxos。

• Basic Paxos：
  • 主要角色：Client（用户）、Proposer（提议者）、Acceptor（议会议员）、Learning（提案记录者）。
  • 流程：client将提案给到Proposer，Proposer初步地询问Acceptor我们将来讨论这个提案号为N的提案，大多数议员通过后，Proposer将提案分发给Acceptor，Acceptor成功接收了提案后，通知Proposer和Learning，Learning再次备份提案。在此期间有更新的提案提出，之前的提案都会被打断。
• Multi Paxos：
  • 相比较Basic版本，多了一个选出leader的环节，此时的Paxos已经与ZAB协议很相似了。
  • 主要角色：Client（用户）、Server（议员）
  • 流程：Client提交提案给其中一个Server，那个Server先询问所有的Server竞选领导，若大多数同意则晋升，晋升Leader后，可以直接发送提案给所有的Server，让他们进行同步，若Leader一直未过期，则不必继续竞选下一轮Leader。

3. Zookeeper的某个机器挂了，整个集群如何处理？

• 若挂掉的机器是Follower，只要剩下的机子超过半数，则仍然可以工作。
• 若挂了的机器为Leader：ZAB协议进入了崩溃恢复模式，暂停对外服务，进行leader选举（进入发现阶段）。每个Follower都进入Looking状态，每个Looking状态的Follower会发起一个投票，每个Follower第一轮都会投自己，然后再根据 1⃣️zxid最大的（证明事务是最新的，数据完善），2⃣️若zxid一致，则选myid最大的，选出Leader，进入同步阶段，当超过一半的节点同步完成后，Leader才算正式上任。

4. 简述Zookeeper的fastleaderelection选举leader的算法。

假设有 5 台服务器组成的 zookeeper 集群，它们的 id 从 1~5，同时它们也是最新启动的，也就是说没有历史数据，假设这些服务器按照顺序依次启动

• 服务器 1 启动，此时只有它一台服务器启动了，他发出去的报文没有任何响应，所以它的选举状态一直是 looking的状态
• 服务器 2 启动，它与最开始启动的服务器 1 进行通信，互相交换自己的选举结果，由于两者都没有历史数据，所以id 值较大的服务器 2 胜出，但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是 3)，所以服务器 1、2 还是继续保持 looking状态。
• 服务器 3 启动，根据前面的理论分析，服务器 3 成为服务器1、2、3中的老大，而与上面不同的是，此时有三台服务器选举了它，所以它成为了这次选举的 Leader。
• 服务器 4 启动，根据前面的分析，理论上服务器 4 应该是服务器 1、2、3、4中最大的，但是由于前面已经有半数以上的服务器选举了服务器3，所以它只能接收当小弟的命了。
• 服务器 5 启动，同 4 一样当小弟

5. Zookeeper如何保证数据的一致性？

数据一致性的处理发生在同步阶段和广播阶段。

• 同步阶段：

  重新选举出来的新的Leader，需要将自己节点上的信息同步到所有的Follower上，只有当超过半数的Follower同步成功时，新的Leader才能算上任。同步检验的方式是：通过Follower上最大的zxid来比较新的Leader上的zxid是否一致。

• 广播阶段(二阶段提交)：

  Leader发送事务请求到所有的Follower，需要收到半数以上的Follower的回应才能算此次事务写入成功，并向所有的Follower发出Commit指令，为了防止有些指令无法到达Follower，Leader会为每一个Follower建立一个消息队列，将事务信息，与提交信息都放入队列中，保证事务的顺序性。

6. Zookeeper的监听原理?

• 首先需要有一个主线程。
• 主线程内有两个线程 Connect线程，与Listening监听器线程
• Connect线程负责与Zookeeper集群通信
• Listening负责监听响应请求
• Connect将监听器的信息与监听的事件发送给Zookeeper集群，Zookeeper将信息添加到列表中
• 当监听的对象发生变化后，Zookeeper发送消息给监听器
• 监听器线程调用Process方法处理相关业务逻辑

文章永久链接：https://tech.souyunku.com/45753