Zookeeper之ZAB协议

Zookeeper之ZAB协议 概念：

可能很多人会认为zoookeeper就是paxos算法的一个实现，但事实上，zookeeper并没有完全采用paxos算法，而是使用了一种称为Zookeeper Atomic Broadcast（ZAB，Zookeeper原子消息广播协议）的协议作为其数据一致性的核心算法。
ZAB协议并不像Paxos算法那样是一种通用的分布式一致性算法，它是一种特别为zookeeper专门设计的一种支持崩溃恢复的原子广播协议。
在zookeeper中，主要就是依赖ZAB协议来实现分布式数据的一致性，基于该协议，Zookeeper实现了一种主备模式的系统架构来保持集群中个副本之间的数据一致性，表现形式就是使用一个单一的主进程来接受并处理客户端的所有事务请求，并采用ZAB的原子广播协议，将服务器数据的状态变更以事务Proposal的形式广播到所有的副本进程中，ZAB协议的主备模型架构保证了同一时刻集群中只能够有一个主进程来广播服务器的状态变更，因此能够很好地处理客户端大量的并发请求。但是，也要考虑到主进程在任何都有可能出现崩溃退出或重启现象，因此，ZAB协议还需要做到当前主进程当出现上述异常情况的时候，依旧能正常工作。

ZAB核心

ZAB协议的核心是定义了对于那些会改变Zookeeper服务器数据状态的事务请求的处理方式。
即：所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，余下的服务器则称为Follower服务器，Leader服务器负责将一个客户端事务请求转化成一个事物Proposal（提议），并将改Proposal发布给集群中的所有Follower服务器，之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确的反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求其将前一个Proposal进行提交。

ZAB协议介绍：

ZAB协议包括两种基本的模式：崩溃恢复和消息广播。
进入崩溃恢复模式：
当整个服务框架启动过程中，或者是Leader服务器出现网络中断，崩溃退出或重启等异常情况时，ZAB协议就会进入崩溃恢复模式，同时选举产生新的Leader服务器。当选举产生了新的Leader服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式，其中，所谓的状态同步就是数据同步，用来保证集群中过半的机器能够和Leader服务器的数据状态保持一致
进入消息广播模式：
当集群中已经有过半的Follower服务器完成了和Leader服务器的状态同步，那么整个服务框架就可以进入消息广播模式，当一台同样遵守ZAB协议的服务器启动加入到集群中，如果此时集群中已经存在一个Leader服务器在负责进行消息广播，那么加入的服务器就会自觉地进入数据恢复模式：找到Leader所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中。Zookeeper值允许唯一的一个Leader服务器进行事务请求的处理，Leader服务器在接收到客户端的事务请求后，会生成对应的事务提议并发起一轮广播协议，而如果集群中的其他机器收到客户端的事务请求后，那么这些非Leader服务器会首先将这个事务请求转发给Leader服务器。
消息广播：
ZAB协议的消息广播使用原子广播协议，类似于一个二阶段提交过程，针对客户端的事务请求，Leader服务器会为其生成对应的事务Proposal，并将其发送给集群中其余所有的机器，然后再分别收集各自的选票，最后进行事务提交。
在ZAB的二阶段提交过程中，移除了中断逻辑，所有的Follower服务器要么正常反馈leader提出的事务Proposal，要么就抛弃Leader服务器，同时，ZAB协议将二阶段提交中的中段逻辑移除意味着我们可以在过半的Follower服务器已经反馈Ack之后就开始提交事务Propsal了，而不需要等待集群中所有的Follower服务器都反馈响应，但是，在这种简化的二阶段提交模型下，无法处理因Leader服务器崩溃退出而带来的数据不一致，因此ZAB采用了崩溃1恢复模式来解决此问题，另外，整个消息广播协议是基于FIFO特性的TCP协议来进行网络通信，因此能够很容易保证消息广播过程中消息接受于发生的顺序性。
在整个消息广播过程中，Leader服务器会为每个事务请求生成对应的Proposal来进行广播，并且在广播事务Proposal之前，Leader服务器会首先为这个事务Proposal分配一个全局单调递增的唯一ID，称之为事务ID（ZXID），由于ZAB协议需要保证每个消息严格的因果关系，因此必须将每个事务Proposal按照其ZXID的先后顺序来进行排序和处理。
具体过程：在消息广播过程中，Leader服务器会为每一个Follower服务器都各自分配一个单独的队列，然后将需要广播的事务Proposal依次放入这些队列中去，并且根据FIFO策略进行消息发送，每一个Follower服务器在接收到这个事务Proposal之后，都会首先将其以事务日志的形式写入到本地磁盘中去，并且在成功写入后反馈给Leader服务器一个Ack响应。当Leader服务器接收到超过半数Follower的Ack响应后，就会广播一个Commit消息给所有的Follower服务器以通知其进行事务提交，同时Leader自身也会完成对事务的提交，而每一个Follower服务器在接收到Commit消息后，也会完成对事务的体检。
崩溃恢复：
ZAB协议这个基于原子广播协议的消息广播过程，在正常情况下运行非常良好，但是一旦在Leader服务器出现崩溃，或者由于网络原因导致Leader服务器失去了与过半Follower的联系，那么就会进入崩溃恢复模式。在ZAB协议中，为了保证程序的正确运行，整个恢复过程结束后需要选举出一个新的Leader服务器，因此，ZAB协议需要一个高效且可靠的Leader选举算法，从而保证能够快速地选举出新的Leader，同时，Leader选举算法不仅仅需要让Leader自身知道已经被选举为Leader，同时还需要让集群中的所有其他机器也能过快速的感知到选举产生出来的新Leader服务器。
运行时状态：
在ZAB协议的设计中，每个进程都要可能处于如下三种状态之一。
LOOKING:Leader选举阶段。
FOLLOWING:Follower服务器和Leader服务器保存同步状态。
LEADING:Leader服务器作为主进程领导状态。
所有进程初始状态都是LOOKING状态，此时不存在Leader，接下来，进程会试图选举出一个新的Leader，之后，如果进程发现已经选举出新的Leader了，那么它就会切换到FOLLOWING状态，并开始和Leader保持状态同步，处于FOLLOWING状态的进程称为Follower，LEADING状态的进程称为Leader，当Leader崩溃或放弃领导地位时，其余的Follower进程就会转换到LOOKING状态开始新一轮的Leader选举，
一个Follower只能和一个Leader保持同步，Leader进程和所有Follower进程之间都通过心跳检测机制来感知彼此的情况。若Leader能够在超时时间内正常收到心跳检测，那么Follower就会一直与该Leader保持连接，而如果在指定时间内Leader无法从过半的Follower进程那里接受到心跳检测，或者TCP连接断开，那么Leader会放弃当前周期的领导，并转换到LOOKING状态，其他的Follower也会选择放弃这个Leader，同时转换到LOOKING状态，之后会进行新一轮的Leader选举。

ZAB与Paxos的联系和区别

联系：
1.都存在一个类似于Leader进程的角色，由其负责协调多个Follower进程的运行。
2.Leader进程都会等待超过半数的Follower做出正确的反馈后，才会将一个提议进行提交。
3.在ZAB协议中，每个Proposal中包含了一个epoch值，用来代表当前的Leader周期，在Paxos算法中，同样存在这样的一个标识，名字为Ballot。
区别：
Paxos算法中，新选举产生的主进程会进行两个阶段的工作，第一阶段称为度阶段，新的主进程和其他进程通信来收集住进程提出的提议，并将它们提交。第二阶段称为写阶段，当前住进程开始提出自己的提议。
ZAB协议在Paxos基础上添加了同步阶段，此时，新的Leader会确保存在过半的Follower已经提交了之前的Leader周期中的所有事务Proposal。这一同步阶段的引入，能够有效地保证Leader在新的周期中提出事务Proposal之前，所以的进程都已经完成了对之前所有事务Proposal的提交。