Zookeeper的ZAB

Paxos 和 ZAB 和zookeeper的选举机制

Paxos：是分布式一致性的一种思想，主要是少数服从多数的思想。

Paxos算法流程中的每条消息描述如下：
1.Prepare: Proposer生成全局唯一且递增的Proposal ID (可使用时间戳加Server ID)，向所有Acceptors发送Prepare请求，这里无需携带提案内容，只携带Proposal ID即可。
2.Promise: Acceptors收到Prepare请求后，做出“两个承诺，一个应答”。
两个承诺：
a.不再接受Proposal ID小于等于（注意：这里是<= ）当前请求的Prepare请求。
b.不再接受Proposal ID小于（注意：这里是< ）当前请求的Propose请求。
一个应答：
c.不违背以前做出的承诺下，回复已经Accept过的提案中Proposal ID最大的那个提案的Value和Proposal ID，没有则返回空值。
3.Propose: Proposer 收到多数Acceptors的Promise应答后，从应答中选择Proposal ID最大的提案的Value，作为本次要发起的提案。如果所有应答的提案Value均为空值，则可以自己随意决定提案Value。然后携带当前Proposal ID，向所有Acceptors发送Propose请求。
4.Accept: Acceptor收到Propose请求后，在不违背自己之前做出的承诺下，接受并持久化当前Proposal ID和提案Value。
5.Learn: Proposer收到多数Acceptors的Accept后，决议形成，将形成的决议发送给所有Learners。

ZAB（zookeeper，Atomic Broadcast）原子广播：是zookeeper保证分布式一致性的解决方案，思想源于Paxos。
zookeeper的选举机制：也是主要采用少数服从多数的思想，超过半数的选举就算成功。

zookeeper处理请求的写入
zookeeper能保证不同节点的数据的一致性，是通过ZAB来完成的。当zk收到一个client请求写的时候，接收请求的该节点会先将请求发送给leader，leader对该请求加上相应版本和其他信息。
一阶段：leader像所有从节点发送确认请求，大家确认自己的节点版本是否可写，返回相应结果。
二阶段：leader拿到相应结果，半数成功则通知从节点去写，对于版本不对写入不成功的节点，重新拉取leader的数据保证数据一致性。

zk的写数据也是一个分布式事务的典型例子，两阶段提交，不过没有回滚数据，而是采用，重新拉取最新数据的方式来保证数据一致性。

zookeeper的选举机制：
zokeeper选举机制，采取paxos的少数服从多数的思想。每个节点通讯比较自己的版本的大小，或则myid的大小，进行投票。当一个节点票数超过半数则成为leader。zokeeper的leader的选举一部分程度上也跟zk的启动快慢有关，当已有leader后，其它节点只能当从节点。
leader的主要作用是解决Paxos的弊端（活锁）。