关于Zookeeper的原子广播和崩溃恢复

ZAB协议

一、概念

1.ZAB(Zookeeper Atomic Broadcast)是一套专门为Zookeeper设计的用于原子广播和崩溃恢复的协议
2.ZAB基于2PC算法进行设计，利用了过半性和PAXOS算法进行了改进
Atomic Broadcast - 原子广播

二、Atomic Broadcast - 原子广播

1.作用：保证数据一致性。(强一致性+最终一致性)
2.原子广播基于2PC进行设计的
3.2PC - Two Phase Commit - 二阶段提交
        ⑴请求阶段：当协调者收到请求之后，不会立即决定是否要执行这个请求，而是会将请求转发给每一个参与者，等待参与者的反馈信息
        ⑵提交阶段：如果协调者收到所有参与者返回的yes，那么会认为这个请求可以执行，那么就会命令所有参与者执行这个请求

        ⑶中止阶段：只要协调者没有收到所有参与者返回的yes，那么就认为这个请求不能执行，就会拒绝执行这个请求

4.2PC要么执行请求-提交阶段，要么执行请求-中止阶段
5.2PC的核心思想是"一票否决"
6.2PC的优势和劣势一样明显：
      2PC的优势在于理解和实现过程都相对简单；
      2PC的劣势在于非常受外界环境(尤其是网络环境)影响
7.在实际开发中，分布式系统很少直接采用2PC算法，而往往都是在2PC的基础上来进行改变。其中Zookeeper的原子广播就是基于2PC加入了过半性来进行改进
8.原子广播的流程
        ⑴leader接收到请求之后，先把这个请求记录到本地的日志文件log.xxx中。log.xxx文件的位置由dataLogDir属性来决定
        ⑵如果记录失败，则直接报错；如果记录成功，则leader会将请求放到队列中发送给每一个follower，等待follower的反馈信息
        ⑶follower收到队列之后，会将请求从队列中一一取出，然后记录到本地的日志文件log.xxx中。如果记录成功，则follower会给leader返回一个yes；如果记录失败，则follower会给leader返回一个no
        ⑷如果leader收到一半及以上的follower返回的yes，则认为这个请求可以执行，那么leader命令所有的节点执行刚才的请求(事务提交)；如果leader没有收到一半的yes，则认为这个请求不能执行，那么leader命令所有的节点删除刚才的请求(事务回滚)
9.如果follower记录日志失败，但是还需要执行请求的时候，这个时候follower会给leader发送请求，leader收到请求之后，会将请求放到队列中再次发送给follower，follower收到队列之后，会将请求先记录到日志中，然后再执行这个请求。如果这个过程中，日志再次记录失败，则follower会重新发送请求
10.follower返回no的可能 - 日志记录失败
        ⑴日志文件被占用
        ⑵磁盘已满 - 实际生产过程中，如果磁盘满了，那么一般会进行压缩或者清理
        ⑶磁盘损坏
11.当一个节点重新连入集群之后，这个节点会先寻找自己的最大事务id，然后将自己的事务id发送给leader。 leader在收到请求之后，会比较最大事务id是否一致。如果不一致，则leader会将欠缺的操作放到队列中返回给follower，要求follower补齐事务。在事务补齐期间，这个follower不会对外提供服务

三、Fail Over - 崩溃恢复

1.在Zookeeper中，当leader宕机之后，这个Zookeeper不会停止服务，而是会选举出一个新的leader，这个过程称之为崩溃恢复
2.作用：保证集群的高可用 - 分区容忍性
3.Zookeeper会给每一个leader分配一个全局递增的编号，称之为epochid。当leader被选举出来之后，这个leader会将自己的epochid分发给每一个follower。每一个follower收到epochid之后，会将这个epochid存储到本地文件acceptedEpoch中
4.在Zookeeper集群中，事务id实际上由64位二进制(16位十六进制)构成。其中前32位对应的epochid，后32位对应的是实际的事务id。例如事务id为0x400000002表示第4任执行的第2个写操作