zookeeper一致性原理

1.Proxos算法

1.1定义

Paxos的目的是让整个集群的结点对某个值的变更达成一致。Paxos算法基本上来说是个大多数的决定会成个整个集群的统一决定。任何一个点都可以提出要修改某个数据的提案，是否通过这个提案取决于这个集群中是否有超过半数的结点同意（所以Paxos需要集群中的节点数为单数）。
算法中的参与者主要分为三个角色，同时每个参与者又可兼领多个角色:

• Proposer： 提出提案，提案信息包括提案编号和提议的value
• Acceptor： 收到提案后可以接受(accept)提案
• Learner： 只能"学习"被批准的提案

1.2算法内容

第一阶段

1. Proposer希望议案V。首先发出Prepare请求至大多数Acceptor。Prepare请求内容为序列号K；
2. Acceptor收到Prepare请求为编号K后，检查自己手里是否有处理过Prepare请求；
3. 如果Acceptor没有接受过任何Prepare请求，那么用OK来回复Proposer，代表Acceptor必须接受收到的第一个议案；
4. 否则，如果Acceptor之前接受过任何Prepare请求（如：MaxN），那么比较议案编号，如果K<MaxN，则用reject或者error回复Proposer；
5. 如果K>=MaxN，那么检查之前是否有批准的议案，如果没有则用OK来回复Proposer，并记录K；
6. 如果K>=MaxN，那么检查之前是否有批准的议案，如果有则回复批准的议案编号和议案内容（如：<AcceptN, AcceptV>， AcceptN为批准的议案编号，AcceptV为批准的议案内容）。

第二阶段

1. Proposer收到过半Acceptor发来的回复，回复都是OK，且没有附带任何批准过的议案编号和议案内容。那么Proposer继续提交批准请求，不过此时会连议案编号K和议案内容V一起提交（<K, V>这种数据形式）
2. Proposer收到过半Acceptor发来的回复，回复都是OK，且附带批准过的议案编号和议案内容（<pok，议案编号，议案内容>）。那么Proposer找到所有回复中AcceptN最大的那个AccpetV（假设为<pok，AcceptNx，AcceptVx>）作为提交批准请求（请求为<K，AcceptVx>）发送给Acceptor。
3. Proposer没有收到过半Acceptor发来的回复，则修改议案编号K为Kx，并将编号重新发送给Acceptors（重复Prepare阶段的过程）
4. Acceptor收到Proposer发来的Accept请求，如果编号K<MaxN则不回应或者reject。
5. Acceptor收到Proposer发来的Accept请求，如果编号K>=MaxN则批准该议案，并设置手里批准的议案为<K，接受议案的编号，接受议案的内容>，回复Proposer。
6. 经过一段时间Proposer对比手里收到的Accept回复，如果超过半数，则结束流程（代表议案被批准），同时通知Leaner可以学习议案。
7. 经过一段时间Proposer对比手里收到的Accept回复，如果未超过半数，则修改议案编号重新进入Prepare阶段。

Paxos流程图

2.ZAB协议

ZXID是一个64位的数据结构。分为高32位，低32位。（由Leader产生，而且它是自增唯一有顺序性）。高32位用来存储epoch（年号），低32位用来存储事务编号。有2种情况导致高32位会变化：

1. 事务编号满了，触发Leader选举。
2. 集群重启，触发Leader选举
3. Leader宕机，触发Leader选举

2.1定义

• ZooKeeper并没有完全采用Paxos算法，而是使用了一种称之为ZooKeeper Atomic Broadcast（ZAB，ZooKeeper原子广播协议）的协议作为其数据一致性的核心算法。
  ZAB协议并不像Paxos算法那样，是一种通用的分布式一致性算法，它是一种特别为ZooKeeper设计的崩溃恢复的原子消息广播算法。ZooKeeper采用一个单一的主进程接受并处理客户端的所有事务请求，并将服务器数据的状态变更以事务Proposal的形式广播到所有的副本进程上去。
  ZAB协议包含两种基本的模式：

2.2协议简介

ZooKeeper并没有完全采用Paxos算法，而是使用了一种称之为ZooKeeper Atomic Broadcast（ZAB，ZooKeeper原子广播协议）的协议作为其数据一致性的核心算法。
ZAB协议并不像Paxos算法那样，是一种通用的分布式一致性算法，它是一种特别为ZooKeeper设计的崩溃恢复的原子消息广播算法。ZooKeeper采用一个单一的主进程接受并处理客户端的所有事务请求，并将服务器数据的状态变更以事务Proposal的形式广播到所有的副本进程上去。
ZAB协议包含两种基本的模式：

• 崩溃恢复
• 消息广播

ZAB协议包含三个阶段：
● 阶段1：发现（Leader选举过程）
● 阶段2：同步（数据同步过程）
● 阶段3：广播（正式接受请求过程）

崩溃恢复

当整个服务器在启动过程中，或者当Leader服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB协议就会进入恢复模式并通过选举产生新的Leader服务器。

• 当选举产生了新的Leader服务器，同时集群中已经有过半机器与该Leader服务器完成状态同步之后，ZAB协议就会退出恢复模式。这里的状态同步指的就是数据同步，用来保证集群中存在过半的机器能够和Leader服务器的数据保持一致。
• 当集群中有过半的Follower服务器完成和Leader服务器的同步，那么整个服务器集群就可以进入消息广播模式。
• 当新的机器加入集群，由于集群已经存在一个Leader，那么新加入的机器会进入数据同步模式，即找到Leader服务器，并与其进行数据同步。
• 当Leader崩溃退出或者重启，或者及集群中不存在过半的服务器可以和Leader保持正常通信，那么在开始新一轮事务操作前所有机器会使用崩溃恢复协议来达到一个一致性的状态。
  
  ZAB协议规定了如果一个事务Proposal在一台机器上被处理成功，那么应该在所有的机器上都被处理成功，哪怕机器出现故障崩溃。

1. 每个Server会发出一个投票，第一次都是投自己。投票信息：（myid，ZXID）
2. 收集来自各个服务器的投票
3. 处理投票并重新投票，处理逻辑：优先比较ZXID，然后比较myid
4. 统计投票，只要超过半数的机器接收到同样的投票信息，就可以确定Leader
5. 改变服务器状态

消息广播

消息广播类似于一个2PC提交过程。根据客户端的事务请求，Leader服务器会为其生成对应的事务投票（即Proposal）并将其发送给集群中其他服务器，然后在分表搜集各自的选票，最后进行事务提交。
与2PC不同的是，ZAB协议没有中断逻辑（所有Follower要么对Leader提成的事务Ack，要么就不回应），而且当过半的Follower服务器反馈Ack之后就开始提交事务，不用等待所有Follower都反馈。
整个消息广播协议是基于FIFO特性的TCP协议来进行网络通信，因此能够很容易地保证消息广播过程中消息接受与发送的顺序性。

1. Leader接收到消息请求后，将消息赋予一个全局唯一的64位自增id，叫做：Zxid，通过zxid的大小比较即可实现因果有序这一特性。
2. Leader通过先进先出队列(通过 TCP 协议来实现，以此实现了全局有序这一特性)将带有zxid的消息作为一个提案(Proposal)分发给所有Follower。
3. 当Follower接收到Proposal，先将Proposal写到硬盘，写硬盘成功后再向Leader回一个ACK。
4. 当Leader接收到合法数量的ACKs后，Leader就向所有Follower发送COMMIT命令，同时会在本地执行该消息。
5. 当Follower收到消息的COMMIT命令时，就会执行该消息。

数据同步

整个集群完成Leader选举后，Learner会向Leader进行注册，当Learner向Leader完成注册后，就进入数据同步环节，同步过程就是Leader将那些没有在Learner服务器上提交过的事务请求同步给Learner服务器。

• 直接差异化同步
• 先回滚再差异化同步
• 仅回滚同步
• 全量同步