分布式系统中最终要的一块，一致性协议，其中就包括了大名鼎鼎的Paxos算法。
两阶段提交（2PC）
同步阻塞：在二阶段提交的执行过程中，所有参与该事务操作的逻辑都处于阻塞状态，即当参与者占有公共资源时，其他节点访问公共资源不得不处于阻塞状态。
单点问题：若协调器出现问题，那么整个二阶段提交流程将无法运转，若协调者是在阶段二中出现问题时，那么其他参与者将会一直处于锁定事务资源的状态中，而无法继续完成事务操作。
数据不一致：在二阶段的阶段二，执行事务提交的时候，当协调者向所有的参与者发送Commit请求之后，发生了局部网络异常或者是协调者在尚未发送完Commit请求之前自身发生了崩溃，导致最终只有部分参与者收到了Commit请求，于是会出现数据不一致的现象。
太过保守：在进行事务提交询问的过程中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话，此时协调者只能依靠自身的超时机制来判断是否需要中断事务，这样的策略过于保守，即没有完善的容错机制，任意一个结点的失败都会导致整个事务的失败。
三阶段提交（3PC）
zk的ZAB算法
ZAB协议是专门为zookeeper实现分布式协调功能而设计。zookeeper主要是根据ZAB协议是实现分布式系统数据一致性。
zookeeper根据ZAB协议建立了主备模型完成zookeeper集群中数据的同步。这里所说的主备系统架构模型是指，在zookeeper集群中，只有一台leader负责处理外部客户端的事物请求(或写操作)，然后leader服务器将客户端的写操作数据同步到所有的follower节点中。
ZAB的协议核心是在整个zookeeper集群中只有一个节点即Leader将客户端的写操作转化为事物(或提议proposal)。Leader节点再数据写完之后，将向所有的follower节点发送数据广播请求(或数据复制)，等待所有的follower节点反馈。在ZAB协议中，只要超过半数follower节点反馈OK，Leader节点就会向所有的follower服务器发送commit消息。即将leader节点上的数据同步到follower节点之上。
ZAB协议模式
ZAB协议是为分布式协调服务zk专门设计的一种支持崩溃恢复的原子广播协议。在zk中，主要依赖ZAB协议来实现分布式数据一致性。
ZAB协议模式：
- 消息广播
- 崩溃恢复
集群生命周期：
消息广播
step1：
leader接收到事务消息请求后，将消息赋予一个全局唯一的64位自增id，叫做：zxid。通过zxid的大小比较即可实现因果有序这一特性。
step2:
leader通过先进先出队列（通过TCP协议来实现，以此实现了全局有序这一特性）将带有zxid的消息作为一个提案（proposal）分发给所有follower。这个队列叫proposal缓存队列committedLog。
step3:
当follower接收到proposal，先将proposal写到磁盘，写磁盘成功后再向leader返回一个ACK。
step4:
当leader接收到合法数量的ACKs后，leader就向所有follower发送COMMIT命令，同时会在本地执行该消息。
step5:
当follower收到消息的commit命令时，就会执行该消息。
小知识点。这里都在说leader和follower，observer的数据是怎么同步的呢？
step4时，leader会发送INFORM消息，此消息本质上是一个包含了已被Commit的proposal的Commit消息。observer接收这个INFORM消息来更新自己的数据。
存疑：observer肯定是通过INFORM消息来更新自己。
follower：
1、通过INFORM消息。
2、还是自己存了proposal再本地，通过leader的commit消息，执行自己本地的proposal。
这两种方式，不确定。待后续能力提升后更新。
崩溃恢复
崩溃恢复就是leader选举
