ZAB核心：

所有的事务请求都由唯一的Leader进行处理。
leader会将客户的事务封装成一个proposal，并将proposal发个所有follow。
超过半数服务器正确反馈后，leader向follower发送commit，并将事务提交。

问题：

1.如何确定leader
2.为什么要超过半数正确反馈
3.为什么要分为二阶段
4.崩溃了如何恢复

ZAB分为 1.崩溃恢复模式 2.消息广播模式

崩溃恢复模式作用于初始化时和leader崩溃（失联）
消息广播则是选举出leader后并成功同步完数据后，执行的模式

消息广播：

leader收到客户端的事务，或者是别的follower转发的事务，就会将其分二阶段提交
首先发送给各follower，然后等待半数回复，然后提交。
这里和2pc很相似，但由于只要半数回复就提交，那么一旦leader或follower崩溃，无法保证数据一致性
因此ZAB提供了崩溃恢复机制

对于每一个事务，leader会给它分配一个ZXID，这个ZXID是全局唯一的递增id，它用来保证事务执行的先后顺序。
ZXID高32位表示epoch及这是第几任leader发布的proposal，低32位是全局递增计数器生成的唯一id

崩溃恢复：

是要在没有leader的情况下选出leader，并向各follower同步数据
这意味着崩溃恢复需要满足：1。已经被提交的数据在崩溃恢复后依然被提交2.没有提交的数据崩溃恢复之后不应该被提交。

解决方法：
参与选举的follower，具有最大的ZXID，就能当选

数据同步：
新leader当选后，会为每个follower创建一个队列，并将它们缺少的proposal发给他们

选举过程

发现崩溃，或者初始化，向别的机器发送自己的max ZXID
若别的机器的ZXID小于准leader的ZXID，则给它投票
若投票过半，则广播给各个follower告诉它们准leader会成为leader，然后同步信息
若投票不过半，并且超时时间类未出现新leader，则在随机时间后在进行选举