从PAXOS到ZOOKEEPER分布式一致性原理与实践

第一章：分布式架构

分布式的特点

分布性、对等性、并发性、缺乏全局时钟

分布式环境的问题

通信异常、网络分区、三态、节点故障

ACID

原子性
一致性
隔离性
未授权读取（读未提交）
授权读取（读已提交）
可重复读
串行化
持久性

CAP

一致性、可用性、分区容错性 三者最多只能同时满足其中两项

BASE

基本可用（系统出现不可预知故障时，允许损失部分可用性）；
软状态（允许系统中的数据出现中间状态，并认为该状态不影响系统的整体可用性）；
最终一致性（强调系统中的所有数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态）。

第二章：分布式一致性协议

2PC（二阶段提交协议）

阶段一：提交事务请求
阶段二：执行事务提交

3PC（三阶段提交协议）

阶段一：canCommit
阶段二：preCommit
阶段三：doCommit

Paxos算法

paxos算法是莱斯利.兰伯特在1990年提出的一种基于消息传递且具有高度容错特性的一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一。

paxos算法的由来：在古希腊有一个paxos小岛，通过议会的形式通过法令，参与议会的议员之间通过信使进行消息传递，但是这些议员和信使都随时可能离开，因此，议会协议需要保证在这种情况下仍然能够正确的产生法令，并且不冲突。

这个议会的选举就好比分布式系统，随时可能会发生宕机、网络故障等，paxos算法就是在一个可能发生以上异常的系统中，快速并且正确的在集群内部对某个数据的值达成一致。

在paxos算法中有三种角色：Proposor、Acceptor、Learner。 每种角色都有多个，并且每个机器也可能担任多个角色。

Paxos算法的推导过程

• P1:一个Acceptor必须批准它收到的第一个提案
• P2:如果某个value为v的提案被选定了，那么每个编号更高的被选定提案的value必须也是v。
• P2a:如果某个value为v的提案被选定了，那么每个编号更高的被Acceptor接受的提案的value必须也是v。
• P2b:如果某个value为v的提案被选定了，那么之后任何Proposer提出的编号更高的提案的value必须也是v。
• P2c:对于任意的N和V，如果提案[N, V]被提出，那么存在一个半数以上的Acceptor组成的集合S，满足以下两个条件中的任意一个：
  S中每个Acceptor都没有接受过编号小于N的提案。
  S中Acceptor接受过的最大编号的提案的value为V。

Paxos算法的过程（两个阶段）

• 生成提案：
  1.Proposer选择一个提案编号N，然后向半数以上的Acceptor发送编号为N的Prepare请求。
  2.如果一个Acceptor收到一个编号为N的Prepare请求，且N大于该Acceptor已经响应过的所有Prepare请求的编号，那么它就会将它已经接受过的编号最大的提案（如果有的话）作为响应反馈给Proposer，同时该Acceptor承诺不再接受任何编号小于N的提案。

• 提交提案：
  1.如果Proposer收到半数以上Acceptor对其发出的编号为N的Prepare请求的响应，那么它就会发送一个针对[N,V]提案的Accept请求给半数以上的Acceptor。注意：V就是收到的响应中编号最大的提案的value，如果响应中不包含任何提案，那么V就由Proposer自己决定。
  2.如果Acceptor收到一个针对编号为N的提案的Accept请求，只要该Acceptor没有对编号大于N的Prepare请求做出过响应，它就接受该提案。

第三章：Paxos的工程实践

Chubby

第四章：ZooKeeper与Paxos

zookeeper介绍

zookeeper是一个开发源代码的分布式协调服务，由雅虎公司创建，是Google Chubby的开源实现。Zookeeper的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。

zookeeper是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、master选举、分布式锁和分布式队列等功能。

zookeeper可以保证以下分布式一致性特性：

1. 顺序一致性
2. 原子性
3. 单一视图
4. 可靠性
5. 实时性

zookeeper的设计目标：

• 简单的数据模型
  提供分布式程序共享的、树状结构的名字空间来相互协调。
• 可以构建集群
  集群中有一半以上的机器能正常工作，就能正常对外服务。
• 顺序访问
  对于客户端请求，zk都会分配一个全局递增的事务id，反映事务操作的先后顺序。以此来实现更高层次的同步原语。
• 高性能
  全量数据存在于内存中，并直接服务于客户端的所有非事务请求。适合于多读操作。

ZAB协议

ZAB协议是一种特别为ZK设计的崩溃可恢复的原子消息广播算法。 在zk中主要依赖ZAB协议来实现分布式数据一致性，基于这个协议，zk实现了一种主备模式的系统架构来保持集群中各副本之间数据的一致性。

ZK使用一个单一的主进程来接收并处理客户端所有的事务请求，并采用ZAB的原子广播协议将服务器数据的状态变更以事务的形式广播到所有副本进程上去。 （由于同一时刻集群中只有一个主进程来广播消息，因此能够处理大量的客户端并发请求，适用于读请求高的环境）

ZAB协议的两种模式

• 消息广播模式
  leader从客户端收到一个写请求
  leader生成一个新的事务并为这个事务生成一个唯一的ZXID
  leader发送该事务给所有的follows节点
  follower节点将收到的事务请求加入到历史队列中,并发送ack给leader
  当leader收到大多数follower（超过法定数量）的ack消息后，会发送commit请求
  当follower收到commit请求时，会判断该事务的ZXID是不是比历史队列中的任何事务的ZXID都小，如果是则提交，如果不是则等待比它更小的事务的commit
• 崩溃/恢复模式
  选举：当leader崩溃后，集群进入选举阶段，开始选举出潜在的新leader，只要有一个节点得到超半数法定节点的票数的支持，它就可以当选为准 leader。这一阶段的目的是就是为了选出一个prospective leader（PL）。
  发现：PL收集Follower发来的acceptedEpoch，并确定了PL的Epoch和Zxid最大，则会生成一个NEWEPOCH分发给Follower，Follower确认无误后返回ACK给PL。这个一阶段的主要目的是PL生成NEWEPOCH，同时更新Followers的acceptedEpoch，并寻找最新的historylog，赋值给PL的history。
  同步：利用 leader 前一阶段获得的最新提议历史，同步集群中所有的副本。只有当 集群中所有法定节点都同步完成，PL才会成为EL。follower 只会接收 zxid 比自己的 lastZxid 大的提议。这个一阶段的主要目的是同步PL的historylog副本。
  广播：集群恢复到广播模式，开始接受客户端的写请求。同时如果有新的节点加入，还需要对新节点进行同步。这个一阶段的主要目的是接受请求，进行消息广播。

zab协议在恢复阶段，最重要的两点保证是：

1. 已经被处理的消息不能丢
2. 被丢弃的消息不能再次出现

根据上述要求，新选举出来的leader不能包含未提交的proposal，即新选举的leader必须都是已经提交了的proposal的follower服务器节点。同时，新选举的leader节点中含有最高的ZXID。这样做的好处就是可以避免了leader服务器检查proposal的提交和丢弃工作。

leader服务器发生崩溃时分为如下场景：

1. leader在提出proposal时未提交之前崩溃，则经过崩溃恢复之后，新选举的leader一定不能是刚才的leader。因为这个leader存在未提交的proposal。
2. leader在发送commit消息之后，崩溃。就是消息已经发送到队列中。经过崩溃恢复之后，参与选举的follower服务器(刚才崩溃的leader有可能已经恢复运行，也属于follower节点范畴)中有的节点已经是消费了队列中所有的commit消息。即该follower节点将会被选举为最新的leader。剩下动作就是数据同步过程。