zookeeper的理解(2)-ZAB协议

概述

1. ZAB（Zookeeper Atomic Broadcast）协议是为分布式协调服务ZooKeeper专门设计的一种支持崩溃恢复的原子广播协议
2. 这套协议基于2PC算法进行的改进，又引入了PAXOS算法
3. ZAB协议包括两种基本的模式，分别是：
   a. 消息原子广播（保证数据一致性）
   b. 崩溃恢复（解决2pc算法的单点问题）

原子广播

1. 实现Zookeeper所有的节点的信息共享，保证分布式数据一致性
2. 原子广播基于2PC算法进行的改进，不同的是它引入了过半性思想
   (2PC算法链接:https://mp.csdn.net/mdeditor/93787728)
3. 原子广播的核心思想是过半 - 少数服从多数
4. 原子广播无法处理Leader服务器崩溃退出而带来的数据不一致问题的，因此在ZAB协议中添加了另一个模式，即采用崩溃恢复模式来解决这个问题

原子广播流程

1. leader服务器接收到事务请求，会先将该事务写到本地的log文件中
2. leader服务器会为这次请求生成对应的事务Proposal并且为这个事务Proposal分配一个全局递增的唯一的事务ID，即Zxid。之后将Proposal放到队列中发给所有的follower
3. 每一个follower在收到队列之后，会从队列中依次取出事务Proposal，写道本地的事务日志中。如果写成功了，则给leader返回一个ACK消息，如果失败了，向leader返回失败信号
4. 当leader服务器接收到半数的follower的ACK响应之后，就会广播一个Commit消息给所有的follower以通知其进行事务提交，同时leader自身也进行事务提交。若没有收到半数的ack信号，则通知所有的follower执行回滚操作

崩溃恢复(解决单点故障问题，引入了PAXOS算法)

基于PAXOS算法进行设计的：在集群中，需要选举一个leader，各个节点之间通过网络进行消息传递。在集群中，每一个节点都可能会丢失，网络也可能会产生波动。在这种不可靠状态下，如何有效的选举出leader，这就是Paxos要做的事儿

1.当leader服务器出现崩溃、重启等场景，或者因为网络问题导致过半的follower不能与leader服务器保持正常通信的时候，Zookeeper集群就会进入崩溃恢复模式
2.进入崩溃恢复模式后，只要集群中存在过半的服务器能够彼此正常通信，那么就可以选举产生一个新的leader
3.每选举一个新的leader，都会分配一个全局递增的编号 - epochid，新leader上任之后，将当前epochid分发给每一个follower，follower收到epochid之后，将编号写到acceptedEpoch文件中，然后再更新到currentEpoch文件
4.之后当一台同样遵守ZAB协议的服务器启动后加入到集群中时，如果此时集群中已经存在一个Leader服务器在负责进行消息广播，那么新加入的服务器就会自觉地进入数据恢复模式：找到leader所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中