Zookeeper协议篇-Paxos算法与ZAB协议(1)

1982年 ,Lamport与另两人共同发表了论文提出了一种计算机容错理论，为了描述这个理论中的问题，假设了一个问题相关的故事场景，如下:

拜占庭帝国有许多支军队，不同军队的将军之间必须制订一个统一的行动计划，从而做出进攻或者撤退的决定，同时，各个将军在地理上都是被分隔开来的，只能依靠军队的通讯员来进行通讯。然而，在所有的通讯员中可能会存在叛徒，这些叛徒可以任意篡改消息，从而达到欺骗将军的目的。

这就是著名的拜占庭问题，而这个问题就和分布式场景下异步系统和不可靠的协议中达到一致性类似，后来Lamport 在 1990年提出了一个理论上的一致性解决方案，茼时给出了严格的数学证明，Paxos算法由此而生。

Paxos算法

我们首先来看一下，对于一个一致性算法来说，我们应该满足哪几点：

1.所有提出的提案最终只有一个被选定

2.如果没有提案，那么最终没有任何选定的提案

3.当提案被选定后，所有客户端都应该能获取到提案信息

在Paxos算法中，有Proposer、Acceptor以及Learner三种角色，彼此之间通过收发消息来实现通信。在分布式场景下，Acceptor绝不可能只有一个实例存在，防止出现单机故障，因此我们需要满足，多个Acceptor的情况下完成选举操作，因此我们可以指定Proposer都向一个Acceptor集合中发送提案，而这个集合中的所有的Acceptor都可能批准提案，当有足够多的Acceptor批准提案的时候，我们就认为这个提案被选定，而所谓的足够多，只需要满足当前Acceptor集合中的大半Acceptor批准提案即可，并且我们规定每个Acceptor在一次选举过程中，只可以批准一个提案。

算法过程

整个Paxos算法的过程可以总结为两阶段提交的算法执行过程，分为Prepare请求阶段和Accept请求阶段，大体的过程如下:

Prepare阶段：

Proposer会选择一个提案，并且编号为M0,然后向Acceptor集合中发送M0编号的Prepare请求，如果这个时候Acceptor集合中的某个Acceptor收到了这个请求，并且编号M0比当前已经相应的所有的提案的最大编号还要大，那么Acceptor就需要反馈自己处理的最大编号，并且不会再去响应低于M0编号的任何请求。如果没有响应过请求，则会直接响应当前的M0编号的请求。

Accept阶段:

同样的，当Proposer发出的提案请求收到了来自整个Acceptor集合中的过半Acceptor的响应，那么就代表该提案可以生成，这个时候如果响应中过半是无任何提案信息的，则代表当前的提案的取值可以是任意值，如果响应中过半是其他的提案信息，那么则从中找到最大编号的提案的值，这里称为V0，组成**[M0,V0]的Acceptor请求，再次发送给整个Acceptor集合。这个时候Acceptor如果没有通过大于v4sp**  编号的提案，那么则会视为自动同意该提案，同样如果得到了过半数的同意，则当前提案视为通过。

当然在整个过程中，每个Proposer都有自己的周期定时生成不同的提案，并且严格按照上述过程运行，最终一定能保证算法的正确性，同样的，如果Proposer已经要生成更大编号的提案，Accept将收到的最大的编号信息通知给上一个同意的最大提案的Proposer，让其放弃自己的提案，选择最新的最大编号的提案即可。

Zab协议

看了前面的Paxos算法，我们可能会认为Zookeeper就是基于Paxos算法的实现，但是事实上，Zookeeper并不是完全采用的Paxos，而是一种名为Zookeeper Atomic Broadcast，简称ZAB协议的一种支持奔溃恢复的协议作为数据一致性核心算法。ZAB协议定义整个Zookeeper中关于事物消息的处理流程，大致如下:

所有的Zookeeper处理的事物请求必须仅有一个机器来协调处理，这样的机器被称之为Leader服务器，而剩下的其他Zookeeper则称之为Follower，而Leader服务器则是会将客户端的事物请求发给所有的Follwer服务器，等待所有的Follwer服务器的反馈，一旦接受到了超过半数的Follwer服务器的正常完成事物处理的反馈后，Leader服务器就会再次发送一个Commit消息给所有的Follwer服务器，要求将刚刚的事物请求进行提交

而ZAB协议有两种基本的模式，分别为崩溃恢复和消息广播。当整个框架在运行的过程中，或者是当Leader出现网络中断、崩溃重启等异常的情况的时候，ZAB协议就会进入恢复模式，来重新选举一个新的Leader服务器来处理事物请求，当新的Leader服务器选择出来，并且和过半以上的机器实现了状态同步后，ZAB的恢复模式就结束了。这个时候就可以进行ZAB的消息广播模式了，如果在这个过程中有一个新的Zookeeper加入了当前的集群中，就会启动恢复模式，直到实现了和Leader的状态同步为止。

正如上述事物处理的过程一样，Zookeeper中只有Leader可以协调处理事物请求，那么其他的Follower服务器是不是没用了呢？当然不是，在整个Zookeeper集群中，所有的服务器都可以提供对外的请求处理，唯一的区别在于，当Follower服务器接受到了事物请求以后，会转发给Leader，让Leader进行统一处理和协调而已。当然在整个集群的运行过程中会出现很多意外，例如有半数以上的Follower服务器无法与Leader进行正常通信，就会从消息广播模式进入到崩溃恢复模式，从其他的机器中选举一个新的Leader出来,同样的一个Leader的选举必须得到超过半数的机器的支持，所以当整个集群的正常服务的机器超过半数，都可以不停的模式转换，保证集群服务的稳定性，一旦出现问题的机器数量超过了集群的半数，整个集群就不再对外提供事物请求的处理，进入保护模式，仅仅可读。

消息广播

ZAB协议中的消息广播使用的是一个原子广播协议，整体的过程可以看为是一个二阶段提交的过程。客户端的事物请求到来以后，Leader服务器会生成对应的事物Proposal，并且将这个发送给当前集群范围内的其余的所有的机器，并且收集来自所有Follower机器的响应选票信息，而二阶段的过程的具体体现，移除了传统二阶段的中断逻辑处理，因此在收集所有Follower机器的响应过程中，**Leader不需要等待所有机器响应后才执行第二阶段，而是只需要等待半数以上的机器返回对应的响应，即可开启第二阶段。**当然在这种简化的二阶段过程中，有可能会因为Leader突然奔溃，导致数据不一致的情况，当然出现这种情况就需要启动崩溃恢复机制来处理，并且所有的消息都是具有FIFO特性的TCP协议来进行网络通信的，从而保证消息广播过程中的顺序性。

而在第一阶段，Leader机器会将事物消息生成对应的Proposal进行广播，并且会生成一个单调递增的ID，作为事物的ID(ZXID),由于ZAB协议需要保证事物严格的上下顺序性，所以会严格按照ZXID的先后来处理对应的消息。而在消息广播发起后，Leader会为每一个Follower服务器分配一个单独的队列，然后将需要广播出去的事物Proposal依次存放进这个FIFO的队列中，每个Follower机器收到事物消息后，会按照事物日志的方式写入，成功后反馈给Leader机器Ack响应，当收到半数以上的Ack响应后，Leader就会发起第二阶段的Commit消息给所有的Follower机器，并且这个时候Leader也会和Follower一样进行本地事物的提交操作，完成整个消息的传递和提交。

崩溃恢复

前面我们提到过，崩溃恢复机制保障了Leader机器在突然异常的情况下，依然能保障一个事物如果在一台机器上处理成功，那么就应该被所有的机器处理成功。因此ZAB协议的崩溃恢复机制整体需要保障以下两点:

1.所有已经在Leader服务器上提交成功的事物最终要被所有的服务器提交

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！