2pc（两阶段提交）
角色：协调者（一个）、参与者（若干）
第一阶段：提交事务请求
协调者向所有参与者询问是否可以执行事务，并发送事务给各个节点。
然后各个参与者执行事务，并将操作写入本地事务日志，但暂时并不提交。无论执行成功还是失败，都向协调者汇报。
至此，第一阶段结束。
第二阶段：执行事务提交
1）若协调者在第一阶段收到了所有参与者的Yes反馈（事务执行成功），便向所有的参与者发送commit消息。
参与者收到commit消息后执行事务提交操作，执行完向协调者发送ACK反馈，然后释放事务资源。
协调者收到反馈后完成事务。
2）若协调者在第一阶段收到了任何一个参与者的No反馈（事务执行失败）或者协调者等待超时，便向所有的参与者发送回滚请求。
参与者收到消息后执行回滚请求，执行完向协调者发送ACK反馈。
协调者收到所有参与者的ACK反馈完成事务中断。
两阶段提交存在的问题：同步阻塞、单点故障、数据不一致等。
两阶段提交主要用于数据库领域内，解决了分布式事务的原子性问题。
3pc（三阶段提交）
角色（同2pc）：协调者（一个）、参与者（若干）
第一阶段：CanCommit
协调者向所有参与者发送包含事务内容在内的CanCommit请求，询问参与者是否可以执行事务提交操作。
参与者收到CanCommit请求后判断自己是否可以执行事务提交操作，并向协调者发送反馈（Yes/No）
第二阶段：PreCommit
1）如果协调者在第一阶段收到所有参与者的Yes响应，则向所有的参与者发送PreCommit请求。
参与者收到请求后，执行事务操作，暂时不提交，然后反馈给协调者Yes/No响应。
2）如果协调者在第一阶段收到任何一个参与者的No响应或者协调者等待超时，则中断事务。
第三阶段：DoCommit
1）如果协调者在第二阶段所有参与者的Yes响应，则向所有的参与者发送DoCommit请求。
参与者收到请求后，提交事务操作，执行完向协调者发送ACK反馈。
协调者收到反馈后完成事务。
2）如果协调者在第二阶段收到任何参与者的No响应，则向所有的参与者发送事务回滚请求。
参与者收到请求后执行事务的回滚操作，执行完之后向协调者发送ACK反馈。
协调者收到反馈后中断事务。
3pc引入了（参与者）超时机制，在DoCommit阶段，如果参与者无法及时接收到来自协调者的DoCommit或者rebort请求时，会在等待超时后，继续进行事务的提交。解决了2pc的单点故障的问题并减少阻塞。但是仍然存在数据不一致的问题。
paxos算法
角色：proposer（倡议者）、acceptor（接受者）、learner（学习者）
阶段一：Prepare阶段（生成提案）
1.1【倡议者视角】倡议者选择倡议编号n，然后向接受者集合发送Prepare请求，请求中附带倡议编号n。
1.2【接受者视角】对于某个接受者来说，如果接收到带有倡议编号n的Prepare请求，则做如下判断：若倡议编号n比此接受者之前响应过的任何其它Prepare请求附带的倡议编号都大，那么此接受者会给倡议者以响应，并承诺不会响应之后接收到的其它任何倡议编号小于n的请求。另外，如果接受者曾经响应过2.2阶段的Accept请求，则将所有响应的Accept请求中倡议编号最高的倡议内容发送给倡议者，倡议内容包括两项信息：Accept请求中的倡议编号以及其倡议值。若倡议编号n不比此接受者之前响应过的任何其它Prepare请求附带的倡议编号都大，那么此接受者不会给倡议者以响应。
阶段二：Accept阶段（批准提案）
2.1【倡议者视角】如果倡议者接收到过半接受者关于带有倡议编号n的Prepare请求的响应，那么倡议者向这些接受者发送Accept请求，Accept请求附带两个信息：倡议编号n以及倡议值v。倡议值v的选择方式如下：如果在1.2阶段接受者返回了自己曾经接受的具有最高倡议编号Accept请求倡议内容，则从这些倡议内容里面选择倡议编号最高的并将其倡议值作为倡议值v；如果1.2阶段没有收到任何接受者的Accept请求倡议内容，则可以自主任意赋值给倡议值v。
2.2【接受者视角】如果接受者接收到了任意倡议编号为n的Accept请求，则接受者接受此请求，除非在此期间接受者响应过具有比n更高编号的Prepare请求。这里有个特点，一旦接受了Accept请求后，这个倡议值v值就定下了。
通过以上两阶段过程即可选出唯一的倡议值，对于学习者来说，其需要从接受者那里获知到底是哪个倡议值被选出。一个直观的方法如下：每当接受者执行完2.2步骤，即接受某个Accept请求后，由其通知所有学习者其所接受的倡议，这样，学习者很快习得是哪个倡议被最终选出。但是这种方式会导致大量通信，因为任意一个接受者会通知任意一个学习者，如果有m个接受者，n个学习者，则需要m*n次通信。一个替代策略是：从众多学习者中选择一个作为代表，由其从接受者那里获知最终被选出的倡议，然后再由其通知其它学习者，这样可以将通信量降为m+n。但是这个方案中如果这个学习者代表发生故障，其它学习者无从知晓倡议值。考虑到健壮性和通信量两个因素，可以采取折中方法：选出若干学习者作为代表，由这些代表从接受者那里获知最终倡议值，然后通知其它学习者。
通过以上流程，如果有多个并发进程提出各自的倡议值，Paxos就可以保证从中选出且只选出一个唯一确定的倡议值，以此来达到副本状态机保持状态一致的目标。
ZAB协议及Zookeeper
角色：leader（接受所有的事务请求）、follower（历史事务集合）、observer（不参与过半选举，提高读性能）
节点状态：持久的、短暂的、顺序的（节点状态 + Watcher功能——应用场景）
Zookeeper的核心是原子广播，这个机制保了各个server之间的同步。实现这个机制的协议叫做ZAB协议。ZAB协议有两种模式，他们分别是回复模式和广播模式。当服务启动或者在领导者崩溃后，ZAB就进入了恢复模式，当领导者被选出来，且大多数server都完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。
Zookeeper是基于ZAB协议完成的，ZAB协议有两种模式：崩溃恢复以及消息广播，崩溃恢复又包括新leader的选举和消息同步。
消息广播：
所有的事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，而余下的其他服务器则被称为Follower服务器。Leader服务器负责将一个客户端事务请求转换成一个事务Proposal（提议），并将该Proposal分发给集群中所有的Follower服务器。之后Leader服务器需要等待所有的Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确的反馈后，那么Leader服务器就会再次向所有的Follower服务器分发Commit消息，要求其将前一个proposal进行提交。
崩溃恢复（选举和数据同步）：
ZAB中的每个事物都有一个编号（ZXID），ZXID有两部分组成，epoch：选举周期，递增计数器：随事物的到来递增。
1、选举
只需要保证选举出来的leader服务器拥有集群中所有机器的最高编码（即ZXID最大）的事务proposal，那么就可以保证这个新选举出来的leader一定具有最新的历史事务
2、数据同步
leader会为每一个follower服务器准备一个队列，将那些没有被各个follower同步的事务以proposal的形式逐个发送给follower服务器，并在proposal后面紧接着发送一个Commit消息，以表示该事务已经被提交，当follower将数据同步完成之后，leader会将该follower加入到真正可用的follower列表中。
崩溃恢复（算法描述）：
1.1、每个follower会将自己最后接受的事务proposal的epoch发送给准leader
1.2、准leader在收到所有epoch中选择一个最大值，在此基础上加以形成新的选举周期，发送给所有的follower
1.3、follower收到后会更新自己的epoch，并反馈给准leader一个ACK，同事携带历史事务集合
1.4、准leader收到所有的follower的历史事务集合后，会形成初始化事务集合
2.1、准leader将初始化事务几个发送给集群中所有的follower
2.2、follower收到后对于没一个事务，follower都会接受，最后将结果反馈给leader，表示已经接受并处理了初始化事务集合中的事务
2.3、leader收到来自过半的follower的反馈后，就会向所有的leader发送commit消息
Zookeeper选举内部fastleaderelection算法：
每个节点除zxid，还会有一个myid。生成的选票为（myid，zxid）
有两种情况：启动时选举与运行时选举
概念：
外部投票：其他服务发来的投票
内部投票：服务器自身当前的投票
选举轮次：leader周期，可以理解为epoch
pk：比较外部投票与内部投票，确定是否变更内部投票
步骤：
1.每个节点初始化自己的选票（myid，zxid，当前节点选举轮次，被推举的服务器选举轮次，状态）
2.发送初始化选票
3.接受外部选票
4.判断选举轮次，进行PK
5.变更投票，重新发送
6.归档。每个节点将收到的所有外部投票进行归档
7.统计。判断是否有过半的服务器认可当前的内部投票，如果则终止。此节点即为新leader。
