关于2PC提交

（Two Phase Commitment Protocol）当一个事务操作需要跨越多个分布式节点的时候，为了保持事务处理的ACID特性，就需要引入一个“协调者”（TM）来统一调度所有分布式节点的执行逻辑，这些被调度的分布式节点被称为AP。 TM负责调度AP的行为，并最终决定这些AP是否要把事务真正进行提交；因为整个事务是分为两个阶段提交，所以叫2pc。

阶段一：提交事务请求（投票）

1. 事务询问

协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。 

2. 执行事务 

各个参与者节点执行事务操作，并将Undo和Redo信息记录到事务日志中，尽量把提交过程中所有消耗时间的操作和准备都提前完成确保后面100%成功提交事务。 

3. 各个参与者向协调者反馈事务询问的响应 

如果各个参与者成功执行了事务操作，那么就反馈给参与者 yes的响应，表示事务可以执行；如果参与者没有成功执行事务，就反馈给协调者no的响应，表示事务不可以执行， 上面这个阶段有点类似协调者组织各个参与者对一次事务 操作的投票表态过程，因此 2pc 协议的第一个阶段称为“投票阶段”，即各参与者投票表名是否需要继续执行接下去的事务提交操作。

阶段二：执行事务提交

在这个阶段，协调者会根据各参与者的反馈情况来决定最终是否可以进行事务提交操作，正常情况下包含两种可能：执行事务、中断事务。

关于ZAB协议

ZAB（Zookeeper Atomic Broadcast）协议是为分布式协调服务 ZooKeeper专门设计的一种支持崩溃恢复的原子广播协议。在ZooKeeper中，主要依赖ZAB协议来实现分布式数据一致性，基于该协议，ZooKeeper实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。

消息广播

改进版本的2PC

1.对每个消息生成一个zxid(64自增id)

2.带有zxid的消息作为一个propose分发给集群中的每一个follower节点

3.把proposal这个事务写入到磁盘，返回一个ack

4.leader收到合法数量的请求ack以后，再发起commit请求

投票不需要observer的参与，但是必须要和leader节点保持同步

崩溃恢复

1.当leader失去了过半的follower节点的联系

2.当leader服务挂了

集群就会进入崩溃恢复阶段

对于数据恢复来说

1.已经被处理的消失不能丢失

当leader收到合法数量的follower的acks以后，就会向各个follower广播消息（commit命令)，同时也会在本地执行COMMIT并向连接的客户端返回「成功」。如果follower节点收到commit命令之前leader就挂了，会导致部分节点收到commit，部分节点没有收到，而实际上客户端已经收到该事务消息处理成功的回执了。所以在zab协议下需要保证所有机器都要执行这个事务消息。

2.被丢弃的消息不能再次出现

当leader接收到消息请求生成proposal后就挂了，其他follower并没有收到此proposal，因此经过恢复模式重新选了leader后，这条消息是被跳过的。此时，之前挂了的leader重新启动并注册成follower，他保留了被跳过消息的proposal状态，与整个系统的状态是不一致的，需要将其删除。