目录：
一、ZAB协议
1、zxid事务id：
在ZAB协议中，每个事务都有一个编号zxid，其中zxid由两部分组成，高32位是epoch，低32位是递增计数器。
epoch：选举周期。
递增计数器：每来一个事务就+1，新的选举周期后重新开始计数。
2、ZAB协议：
zookeeper核心是原子广播，原子广播机制保证了各个server之间的数据同步，实现原子广播机制的协议叫ZAB协议。
ZAB协议主要包括两种模式，恢复模式+广播模式。当服务启动或leader崩溃后，ZAB就进入了恢复模式。当领导者被选举出来，且大多数server完成了和leader的状态同步后，恢复模式结束。其中状态同步保证了leader和server具有相同的系统状态。
3、故障恢复+消息广播
（1）故障恢复：选举+数据同步
基本思想：
选举：保证选举出的leader拥有集群中所有机器的最高zxid
数据同步：leader会为每个follower准备一个队列，将那些没有被followr同步的事务以proposal提议的形式发送给follower服务器，并在proposal后面加上一个commit，表示该事务已经被提交。只有当follower将事务同步完成之后，leader才会将该follower加入到真正可用的follower列表当中。
先进行选举，选举完成后，执行故障恢复，也就是数据同步。
算法描述：
- 每个follower将自己最后接受的事务proposal提议的epoch选举周期发送至准leader。
- 准leader在收到的这些epoch当中选出一个最大值，+1后形成新的选举周期，并将epoch发送给所有的follower。
- follower收到epoch后，返回给准leader一个ack和历史事务集合。
- 准leader收到历史事务集合后，会形成初始化事务集合。
- 准leader将初始化事务集合发送给所有的follower。
- follower收到事务集合后，对于其中的每个事务都会接受，并将结果返回给leader，表示已经接受并处理了这些事务。
- leader收到了过半的follower的反馈后，向所有的leader发送commit消息。
（2）消息广播：
1、发送给集群中所有的follower。
2、收到过半的ack。
3、发送commit提交事务。
二、2PC+paxos
zookeeper的ZAB协议就是用的这两种思想：
消息同步，用两阶段提交思想
leader选举，用paxos算法思想
一、2PC两阶段提交：
两阶段提交协议（Two-phase Commit，2PC）经常被用来实现分布式事务
在分布式事务中，每个机器节点只能够明确知道自己事务操作的结果，是成功还是失败，而无法获取其他分布式节点的操作结果，因此在事务操作需要跨多个分布式节点时，需要引入一个协调者统一调度所有节点的执行逻辑。
阶段一：提交事务请求
（1）事务询问。协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
（2）执行事务。各参与者节点执行事务操作，并将Undo和Redo信息记入事务日志中。
（3）各参与者向协调者反馈事务询问的响应。如果参与者成功执行了事务操作，那么久反馈给协调者yes响应，表示事务可以执行；如果参与者没有成功执行事务，那么久反馈给协调者No响应，表示事务不可以执行。
阶段二：执行事务提交
在阶段二中，协调者会根据各参与者的反馈情况，来决定最终是否可以进行事务提交操作，正常情况下，包含以下两种可能。
（1）执行事务提交：假如协调者从所有的参与者获得的反馈都是yes响应，那么就会执行事务提交。
a、发送提交请求。协调者向所有参与者节点发出Commit请求。
b、事务提交。参与者接收到Commit请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源。
c、反馈事务提交结果。参与者在完成事务提交之后，向协调者发送Ack消息。
d、完成事务。协调者接收到所有参与者反馈的Ack消息后，完成事务。
（2）中断事务：假如任何一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，就会中断事务
a、发送回滚请求。协调者向所有参与者节点发出Rollback请求
b、事务回滚：参与者接收到Rollback请求后，会利用其在阶段一中记录的Undo信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源
c、反馈事务回滚结果：参与者在完成事务回滚之后，向协调者发送Ack消息
d、中断事务：协调者接收到所有参与者反馈的Ack消息后，完成事务中断
二阶段提交将一个事务的处理过程分为了投票和执行两个阶段，其核心是对每个事务都采用先尝试后提交的处理方式，因此也可以将二阶段提交看作一个强一致性的算法，下图分别展示了二阶段提交过程中事务提交和事务中断两种场景下的交互流程：
两阶段提交的优缺点：
优点：原理简单，实现方便。
缺点：同步阻塞、单点问题、脑裂、太过保守。
二、paxos
一个分布式系统如何就某个值（决议）达成一致
paxos算法解决的问题是，如何在一个可能发生宕机或者网络异常的分布式系统中，快速且正确的在集群内部对某个数据的值达成一致。
问题：假设有一组可以提出提案的进程集合，对于一致性的算法需要满足：被提出的提案只能有一个题案产生；假设一个提案被选定后，进程可以获取被选定的提案信息。
组成：Acceptor、Proposer、Leaner。
（1）生成提案
a、Proposer选择一个新的提案编号Mn，然后向某个Acceptor集合的成员发出请求，要求该集合中的Acceptor做出如下回应。
向Proposer承诺，保证不再批准比任何编号小于Mn的提案。如果Acceptor已经批准过任何提案，那么其就向Proposer反馈当前该Acceptor已经批准的编号小于、但为最大编号的那个提案值。我们将该请求称为编号为Mn的提案的prepare请求。
b、如果Proposer收到了来自半数以上的Acceptor的响应结果，那么它就可以产生编号为Mn，值为Vn的提案，这里的Vn是所有响应中编号最大的提案的Value值。
如果半数以上的Acceptor没有批准过任何提案，即响应中不包含任何的提案，那么此时Vn的值可以由Proposer任意指定。
（2）批准提案
一个Acceptor可能收到来自Proposer的两种请求，分别是prepare请求和Accept请求，对这两类请求的响应条件如下：
prepare请求：Acceptor可以在任何时候响应一个prepare请求。
Accept请求：在不违背Accept现有承诺的前提下，可以任意响应Accept请求。
总之，一个acceptor只要尚未响应过任何编号大于Mn的prepare请求，那么它就可以接受这个编号为Mn的提议。
参考博客：https://blog.csdn.net/qq_40378034/article/details/99681137
https://www.cnblogs.com/Leo_wl/p/6002110.html