深入浅出Zookeeper中的ZAB协议

　　本文主要内容如下：
　　ZAB协议的全称是ZookeeperAtomicBroadcase，原子广播协议。
　　作用：通过这个ZAB协议可以进行集群间主备节点的数据同步，保证数据的一致性。
　　在讲解ZAB协议之前，我们必须要了解Zookeeper的各节点的角色。Zookeeper各节点的角色Leader负责处理客户端发送的读、写事务请求。这里的事务请求可以理解这个请求具有事务的ACID特性。同步写事务请求给其他节点，且需要保证事务的顺序性。状态为LEADING。Follower负责处理客户端发送的读请求转发写事务请求给Leader。参与Leader的选举。状态为FOLLOWING。Observer
　　和Follower一样，唯一不同的是，不参与Leader的选举，且状态为OBSERING。
　　可以用来线性扩展读的QPS。启动阶段，如何选Leader？
　　Zookeeper刚启动的时候，多个节点需要找出一个Leader。怎么找呢，就是用投票。
　　比如集群中有两个节点，A和B，原理图如下所示：
　　节点A先投票给自己，投票信息包含节点id（SID）和一个ZXID，如（1，0）。SID是配置好的，且唯一，ZXID是唯一的递增编号。节点B先投票给自己，投票信息为（2，0）。然后节点A和B将自己的投票信息投票给集群中所有节点。节点A收到节点B的投票信息后，检查下节点B的状态是否是本轮投票，以及是否是正在选举（LOOKING）的状态。投票PK：节点A会将自己的投票和别人的投票进行PK，如果别的节点发过来的ZXID较大，则把自己的投票信息更新为别的节点发过来的投票信息，如果ZXID相等，则比较SID。这里节点A和节点B的ZXID相同，SID的话，节点B要大些，所以节点A更新投票信息为（2，0），然后将投票信息再次发送出去。而节点B不需要更新投票信息，但是下一轮还需要再次将投票发出去。
　　这个时候节点A的投票信息为（2，0），如下图所示：
　　统计投票：每一轮投票，都会统计每台节点收到的投票信息，判断是否有过半的节点收到了相同的投票信息。节点A和节点B收到的投票信息都为（2，0），且数量来说，大于一半节点的数量，所以将节点B选出来作为Leader。更新节点状态：节点A作为Follower，更新状态为FOLLOWING，节点B作为Leader，更新状态为LEADING。运行期间，Leader宕机了怎么办？
　　在Zookeeper运行期间，Leader会一直保持为LEADING状态，直到Leader宕机了，这个时候就要重新选Leader，而选举过程和启动阶段的选举过程基本一致。
　　需要注意的点：剩下的Follower进行选举，Observer不参与选举。投票信息中的zxid用的是本地磁盘日志文件中的。如果这个节点上的zxid较大，就会被当选为Leader。如果Follower的zxid都相同，则Follower的节点id较大的会被选为Leader。节点之间如何同步数据的？
　　不同的客户端可以分别连接到主节点或备用节点。
　　而客户端发送读写请求时是不知道自己连的是Leader还是Follower，如果客户端连的是主节点，发送了写请求，那么Leader执行2PC（两阶段提交协议）同步给其他Follower和Observer就可以了。但是如果客户端连的是Follower，发送了写请求，那么Follower会将写请求转发给Leader，然后Leader再进行2PC同步数据给Follower。
　　两阶段提交协议：第一阶段：Leader先发送proposal给Follower，Follower发送ack响应给Leader。如果收到的ack过半，则进入下一阶段。第二阶段：Leader从磁盘日志文件中加载数据到内存中，Leader发送commit消息给Follower，Follower加载数据到内存中。
　　我们来看下Leader同步数据的流程：
　　客户端发送写事务请求。Leader收到写请求后，转化为一个proposal01：zxid1事务请求，存到磁盘日志文件。发送proposal给其他Follower。Follower收到proposal后，Follower写磁盘日志文件。
　　接着我们看下Follower收到Leader发送的proposal事务请求后，怎么处理的：
　　Follower返回ack给Leader。Leader收到超过一半的ack，进行下一阶段Leader将磁盘中的日志文件的proposal加载到znode内存数据结构中。Leader发送commit消息给所有Follower和Observer。Follower收到commit消息后，将磁盘中数据加载到znode内存数据结构中。
　　现在Leader和Follower的数据都是在内存数据中的，且是一致的，客户端从Leader和Follower读到的数据都是一致的。ZAB的顺序一致性怎么做到的？
　　Leader发送proposal时，其实会为每个Follower创建一个队列，都往各自的队列中发送proposal。
　　如下图所示是Zookeeper的消息广播流程：
　　客户端发送了三条写事务请求，对应的proposal为proposal01：zxid1proposal02：zxid2proposal03：zxid3
　　Leader收到请求后，依次放到队列中，然后Follower依次从队列中获取请求，这样就保证了数据的顺序性。Zookeeper到底是不是强一致性？
　　官方定义：顺序一致性。
　　不保证强一致性，为什么呢？
　　因为Leader再发送commit消息给所有Follower和Observer后，它们并不是同时完成commit的。
　　比如因为网络原因，不同节点收到的commit较晚，那么提交的时间也较晚，就会出现多个节点的数据不一致，但是经过短暂的时间后，所有节点都commit后，数据就保持同步了。
　　另外Zookeeper支持强一致性，就是手动调用sync方法来保证所有节点都commit才算成功。
　　这里有个问题：如果某个节点commit失败，那么Leader会进行重试吗？如何保证数据的一致性？欢迎讨论。Leader宕机数据丢失问题
　　第一种情况：假设Leader已经将消息写入了本地磁盘，但是还没有发送proposal给Follower，这个时候Leader宕机了。
　　那就需要选新的Leader，新Leader发送proposal的时候，包含的zxid自增规律会发生一次变化：zxid的高32位自增1一次，高32位代表Leader的版本号。zxid的低32位自增1，后续还是继续保持自增长。
　　当老Leader恢复后，会转成Follower，Leader发送最新的proposal给它时，发现本地磁盘的proposal的zxid的高32位小于新Leader发送的proposal，就丢弃自己的proposal。
　　第二种情况：如果Leader成功发送了commit消息给Follower，但是所有或者部分Follower还没来得及commit这个proposal，也就是加载磁盘中的proposal到内存中，这个时候Leader宕机了。
　　那么就需要选出磁盘日志中zxid最大的Follower，如果zxid相同，则比较节点id，节点id大的作为Leader。
　　原文链接：https：mp。weixin。qq。comsPtbenxM1vzUdtPLLsA9J7w