Zab（Zookeeper Atomic Broadcast）

保证数据一致性，多副本之间数据一致性

恢复模式
消息广播模式


恢复模式
选举阶段
数据同步阶段
zxid=epoch+xid


消息广播模式  
消息广播 propose ack commit
2pc



分布式事务
2PC，3PC， TCC(try, commit, cancel)

2PC Two-Phase Commit 二阶段提交协议     准备阶段+提交阶段
3PC Three-Phase Commit 三阶段提交协议   CanCommit + PreCommit + Commit

参与者收到PreCommit请求后，执行事务操作，将Undo和Redo信息记入事务日志中（但不提交事务）

2PC 问题   同步阻塞、单点、脑裂
3PC 增加超时机制


都存在脑裂问题，无法解决 分布式一致性问题

解决一致性问题，唯有Paxos 


zk特点

一个leader，多个follower，多个observer（只读），只有leader能写，follow提供读和选举投票

Observer模式
peerType=observer

server.1:localhost:2181:3181:observer

老版本中没有observer，增加follower节点，提升读性能 ，但是写性能会严重下降
有了observer，增加observer节点，observer不参与投票，不会引起写性能下降



节点数要求 2N+1，在写或者选举时需要N+1个节点通过才能成功

只有leader能写，保证写的顺序性 

leader 奔溃，借助(myid, zxid) 比较大小来选举，最大的为新的leader

适用于读多写少的场景

节点的数据大小不能超过1M

Zxid  64 位数字  
高 32 位 代表 Leader 周期 epoch  
低 32 位 单调递增的计数器，客户端每一个事务请求，计数器加 1


leader epoch 朝代 年号 

follower只接收比自己lastZxid 大的zxid的提议
follower 只听从当前年代的 leader 的命令


历史队列(history queue)
每一个follower节点都会有一个先进先出（FIFO)的队列用来存放收到的事务请求，保证执行事务的顺序

可靠提交由ZAB的事务一致性协议保证
全局有序由TCP协议保证
因果有序由follower的历史队列(history queue)保证

广播(broadcast) 执行过程

leader从客户端收到一个写请求
leader生成一个新的事务并为这个事务生成一个唯一的ZXID，
leader将这个事务发送给所有的follows节点
follower节点将收到的事务请求加入到历史队列(history queue)中,并发送ack给ack给leader
当leader收到大多数follower（超过法定数量）的ack消息，leader会发送commit请求
当follower收到commit请求时，会判断该事务的ZXID是不是比历史队列中的任何事务的ZXID都小，如果是则提交，如果不是则等待比它更小的事务的commit

恢复模式大致可以分为四个阶段
选举 发现 同步 广播
当leader崩溃后，集群进入选举阶段，开始选举出潜在的新leader(一般为集群中拥有最大ZXID的节点)
进入发现阶段，follower与潜在的新leader进行沟通，如果发现超过法定人数的follower同意，则潜在的新leader将epoch加1，进入新的纪元。新的leader产生
集群间进行数据同步，保证集群中各个节点的事务一致
集群恢复到广播模式，开始接受客户端的写请求