zk基础—1.一致性原理和算法一

大纲

1.分布式系统特点

2.分布式系统的理论

3.两阶段提交Two-Phase Commit(2PC)

4.三阶段提交Three-Phase Commit(3PC)

5.Paxos岛的故事来对应ZooKeeper

6.Paxos算法推导过程

7.Paxos协议的核心思想

8.ZAB算法简述

1.分布式系统特点

(1)分布性

(2)对等性

(3)并发性

(4)缺乏全局时钟

(5)故障随时会发生

分布式系统的特点：分布性、对等性、并发性、缺乏全局时钟、故障随时会发生。

(1)分布性

既然是分布式系统，最显著的特点肯定就是分布性。比如电商项目会分成不同的功能，或者不同的微服务。这些服务部署在不同的服务器中，甚至不同的集群中。整个架构都是分布在不同的地方的，在空间上是随意的，而且随时会增加、删除服务器节点。

(2)对等性

对等性是分布式设计的一个目标。比如订单服务，为了防止订单服务出现问题，一般需要有一个备份，在订单服务出现问题时能顶替原来的订单服务。这就要求这两个或两个以上的订单服务完全是对等的，功能完全是一致的。这其实就是服务副本的冗余，当然还有数据副本的冗余，比如数据库、缓存等。

(3)并发性

在一个分布式系统中的多个节点，可能会并发地操作一些共享资源，可以通过分布式锁来准确、高效地协调分布式并发操作。

(4)缺乏全局时钟

在分布式系统中，节点可能会在任意位置，每个位置上的节点都会有自己的时间系统。因此在分布式系统中，很难定义两个事务究竟谁先谁后，原因就是因为缺乏一个全局的时钟序列进行控制。当然现在这已不是什么问题，已有很多时间服务器提供给系统调用。

(5)故障随时会发生

任何一个节点都可能出现停电、死机等现象，服务器集群越多，出现故障的可能性就越大。随着集群数目的增加，出现故障甚至都会成为一种常态。

2.分布式系统的理论

(1)分布式系统带来的问题

(2)CAP理论

(3)BASE理论

(4)分布式一致性算法

(1)分布式系统带来的问题

分布式系统主要会有：通讯异常、网络分区、三态、节点故障等问题。

一.通信异常

通讯异常其实就是网络异常。网络系统本身就是不可靠的，由于分布式系统需要通过网络进行数据传输，网络硬件难免出现问题。只要网络出现问题，就会影响消息的发送与接受过程，因此数据消息的丢失或者延长就会变得非常普遍。

二.网络分区

网络分区，其实就是脑裂现象。同一个分布式集群出现两个相互冲突的决策者时，就是网络分区。脑裂产生原因是网络故障后出现了两个决策者。

三.三态

三态就是成功与失败以外的第三种状态，即超时态。在一个JVM中，应用程序调用一个方法函数后会得到一个明确的响应：要么成功，要么失败。在分布式系统中，虽然绝大多数情况下能接受到成功或者失败的响应，但一旦网络出现异常就非常有可能出现超时。当出现这种超时现象，网络通讯的发起方是无法确定请求是否成功处理的。

四.节点故障

节点故障在分布式系统下是比较常见的问题，指的是组成服务器集群的节点会出现的宕机或僵死的现象。

(2)CAP理论

CAP指的是一致性(C)、可用性(A)、分区容错性(P)这三个词的缩写。

一.一致性Consistency

在分布式系统中，一致性是数据在多个副本之间是否能够保证一致的特性。如果在分布式系统中针对某一个数据项的变更成功执行后，所有用户都能马上读取到最新值，则这样的系统就被认为具有强一致性。

二.可用性Avaliable

可用性指系统提供服务必须一直处于可用状态，对于用户的操作请求总是能够在有限的时间内访问结果。这里的重点是：有限的时间和返回结果。为了做到有限的时间需用到缓存和负载，这时增加节点是为考虑性能。为了返回结果需考虑节点主备，当主节点出现问题时备节点能快速顶上来。

三.分区容错性

分布式系统在遇到任何网络分区故障时，仍然需要能够对外提供满足一致性和可用性的服务，不能出现脑裂的情况，除非整个网络环境都发生了故障。

CAP理论具体描述：一个分布式系统不可能同时满足一致性、可用性和分区容错性，最多只能同时满足其中的两项。

注意：P是不能放弃的，不可能把所有应用全部放到一个节点上。A和C也不能全部放弃，因此要在A和C间寻求平衡，平衡的基础就是BASE理论。

(3)BASE理论

BASE理论：即使无法做到强一致性，但分布式系统可以根据自己的业务特点，采用适当的方式来使系统达到最终的一致性。

一.Basically Avaliable基本可用

当分布式系统出现不可预见的故障时，允许损失部分可用性，保障系统的基本可用，体现在响应时间上的损失和功能上的损失。例如：大促高峰部分用户的页面卡顿会使用降级处理。

二.Soft State软状态

其实就是前面讲到的三态，即允许系统中的数据存在中间状态。不同节点的数据副本进行数据同步的过程存在延时，并不影响系统可用性。例如：通过消费消息队列更新本地缓存。

三.Eventually Consistent最终一致性

所有的数据副本在经过一段时间的同步后，最终能达到一个一致的状态。例如：手机充值总金额短时不到账，但一段时间后一定到账。

BASE理论一句话概括：就是平时系统要基本可用，除了成功失败，运行时允许出现可容忍的延迟状态，但是无论如何经过一段时间的延迟后系统最终必须达到数据是一致的。

(4)分布式一致性算法

不管是CAP理论，还是BASE理论，这些理论都需要算法来实现。2PC、3PC、Paxos算法、ZAB算法就是用来实现CAP、BASE理论的。这些理论的前提一定是分布式，解决的问题都是：在分布式环境下，怎么让系统尽可能高可用，且数据能最终能达到一致。

3.两阶段提交Two-Phase Commit(2PC)

(1)数据库事务通过undo和redo保证数据强一致性

(2)分布式事务通过2PC保证数据强一致性

(3)2PC的优点和缺点

(1)数据库事务通过undo和redo保证数据强一致性

2PC即二阶段提交算法，是强一致性算法。它是数据库领域内，为了使基于分布式系统架构下的所有节点，在进行事务处理过程中能够保持原子性和一致性而设计的算法。所以很适合用作数据库的分布式事务，其实数据库经常用到的TCC本身就是一种2PC。

在InnoDB存储引擎中，对数据库的事务修改都会写undo日志和redo日志。其实不只是数据库，很多需要事务支持的都会用到undo和redo思路。

一.对数据的修改操作首先写undo日志记录数据原值

二.然后执行事务修改操作，把修改写到redo日志里

三.万一事务失败了，可以从undo日志恢复数据

数据库通过undo和redo能保证数据强一致性。

(2)分布式事务通过2PC保证数据强一致性

解决分布式事务的前提就是节点是支持事务的。在这个前提下，2PC把整个分布式事务分两个阶段：投票阶段(Prepare)和执行阶段(Commit)。

阶段一：投票阶段

在阶段一中，各参与者投票表明是否要继续执行接下来的事务提交操作。

步骤一：协调者向参与者发起事务询问。协调者向所有的参与者发送事务内容，询问是否可以执行事务操作，并开始等待各参与者的响应。

步骤二：参与者收到协调者的询问后执行事务。各参与者节点执行事务操作，并将undo和redo信息记入事务日志中。

步骤三：参与者向协调者反馈事务询问的响应。如果参与者成功执行事务操作，就反馈协调者Yes响应，表示事务可执行。如果参与者没成功执行事务，就反馈协调者No响应，表示事务不可执行。

阶段二：执行阶段

在阶段二中，协调者会根据各参与者的反馈来决定是否可以进行事务提交。有两种提交可能：执行事务提交和中断事务。

可能一：执行事务提交

假如协调者从所有参与者获得的反馈都是Yes响应，那么就会执行事务提交。

步骤一：协调者向参与者发送提交请求，协调者向所有参与者节点发出Commit请求。

步骤二：参与者收到协调者的Commit请求后进行事务提交。参与者接收到Commit请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源。

步骤三：参与者向协调者反馈事务提交结果(Ack消息)。参与者在完成事务提交之后，向协调者发送Ack消息。

步骤四：协调者收到所有参与者反馈(Ack)后完成事务。协调者接收到所有参与者反馈的Ack消息后，完成事务。

可能二：中断事务

假如任何一个参与者向协调者反馈了No响应或者等待超时，那么协调者无法接收到所有参与者的反馈响应，就会中断事务。

步骤一：协调者向参与者发送回滚请求，协调者向所有参与者节点发出Rollback请求。

步骤二：参与者收到协调者的Rollback请求后进行事务回滚。参与者接收到Rollback请求后，会利用undo信息来执行事务回滚操作，并在完成回滚之后释放占用的事务资源。

三.参与者向协调者反馈事务回滚结果(Ack消息)。参与者在完成事务回滚之后，向协调者发送Ack消息。

四.协调者收到所有参与者反馈(Ack)后中断事务。协调者接收到所有参与者反馈的Ack消息后，完成事务中断。

(3)2PC的优点和缺点

一.2PC优点

优点一：原理简单

优点二：实现方便

二.2PC缺点

总结来说有四个缺点：同步阻塞、单点故障、数据不一致、容错机制不完善。

缺点一：同步阻塞

在二阶段提交过程中，所有节点都在等其他节点响应，无法进行其他操作，这种同步阻塞极大的限制了分布式系统的性能。

缺点二：单点问题

协调者在整个二阶段提交过程中很重要。如果协调者在提交阶段出现问题，那么整个流程将无法运转。而且其他参与者会处于一直锁定事务资源的状态中，无法完成事务操作。

缺点三：数据不一致

假设当协调者向所有参与者发送Commit请求后，发生了局部网络异常。或者是协调者在尚未发送完所有Commit请求之前自身发生了崩溃，导致最终只有部分参与者收到了Commit请求，那么这会出现部分参与者的数据不一致问题。

缺点四：容错性不好

二阶段提交协议没有较为完善的容错机制，任意一个参与者或协调者故障都会导致整个事务的失败。

4.三阶段提交Three-Phase Commit(3PC)

(1)第一阶段canCommit

(2)第二阶段preCommit

(3)第三阶段doCommit

(4)3PC的优缺点

(5)3PC与2PC区别

(1)第一阶段canCommit

步骤一：协调者向参与者发起事务询问。协调者向所有参与者发送一个包含事务内容的canCommit请求。询问是否可以执行事务提交操作，并开始等待各参与者响应。

步骤二：参与者收到协调者的询问后反馈响应。参与者在接收到协调者的canCommit请求后，如果认为可以顺利执行事务，会反馈Yes响应并进入预备状态，否则反馈No响应。

这一阶段其实就是确认所有的资源是否都是健康、在线的。因为有了这一阶段，大大的减少了2PC提交的阻塞时间。

因为这一阶段优化了以下这种情况：2PC提交时，如果有两个参与者，恰好参与者2出现问题，参与者1执行了耗时的事务操作，最后却发现参与者2连接不上，参与者1白执行耗时操作了。

(2)第二阶段preCommit

包含两种可能：执行事务预提交和中断事务。

可能一：执行事务预提交

假如协调者从所有参与者获得的反馈都是Yes响应，则执行事务预提交。

步骤一：协调者向参与者发送预提交请求，协调者向所有参与者发出preCommit请求，然后协调者会进入预提交状态。

步骤二：参与者收到协调者的preCommit请求后执行事务。参与者接收到协调者发出的preCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。

步骤三：参与者向协调者反馈事务执行的响应(Ack)。如果参与者成功执行了事务操作，那么就会反馈给协调者一个Ack响应。

可能二：中断事务

假如任何一个参与者向协调者反馈了No响应，或者等待超时。协调者无法接收到所有参与者的反馈响应，那么就会中断事务。

步骤一：协调者向参与者发送中断请求，协调者向所有参与者节点发出abort请求。

步骤二：参与者收到协调者abort请求则中断事务。无论是收到来自协调者的abort请求，或者在等待协调者请求过程中出现超时，参与者都会中断事务。

(3)第三阶段doCommit

包含两种可能：执行提交和中断事务。

可能一：执行提交

接收到来自所有参与者的Ack响应。

步骤一：协调者向参与者发送提交请求。协调者向所有参与者发出doCommit请求，然后协调者会由预提交状态进入提交状态。

步骤二：参与者收到协调者的doCommit请求后提交事务。参与者接收到doCommit请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行期间占用的事务资源。

步骤三：参与者向协调者反馈事务提交结果。参与者在完成事务提交之后，向协调者发送Ack消息。

步骤四：协调者收到所有参与者反馈(Ack)完成事务。协调者接收到所有参与者反馈的Ack消息后，完成事务。

可能二：中断事务

假如任何一个参与者向协调者反馈了No响应，或者等待超时。协调者无法接收到所有参与者的反馈响应，那么就会中断事务。

步骤一：协调者向参与者发送回滚请求，协调者向所有参与者节点发出abort请求。

步骤二：参与者收到协调者的abort请求后进行事务回滚。参与者接收到协调者的abort请求后，会利用undo信息执行事务回滚操作，并在完成回滚之后释放占用的事务资源。

步骤三：参与者向协调者反馈事务回滚结果(Ack消息)。参与者在完成事务回滚之后，会向协调者发送Ack消息。

步骤四：协调者收到所有参与者反馈(Ack)后中断事务。协调者接收到所有参与者反馈的Ack消息后，完成事务中断。

注意：一旦进入阶段三doCommit，无论出现哪一种故障：协调者出现了问题、协调者和参与者之间网络故障，最终都会导致参与者无法及时接收来自协调者的doCommit或abort请求。参与者都会在等待超时后，继续进行事务提交。

(4)3PC的优缺点

三阶段提交协议的优点

优点一：改善同步阻塞

与2PC相比，降低了参与者的阻塞范围。

优点二：改善单点故障

与2PC相比，出现单点故障后能继续达成一致。

三阶段提交协议的缺点

缺点一：同步阻塞

相比2PC虽然降低阻塞范围，但依然存在阻塞。

缺点二：单点故障

虽然单点故障后能继续提交，但单点故障依然存在。

缺点三：数据不一致

正是因为出现单点故障后可以继续提交，所以可能会出现数据不一致。

缺点四：容错机制不完善

参与者或协调者节点失败会导致事务失败，所以数据库的分布式事务一般都是采用2PC，而3PC更多是被借鉴扩散成其他的算法。

(5)3PC与2PC区别

区别一：3PC第二阶段才写undo和redo事务日志。

区别二：3PC第三阶段协调者出现异常或网络超时参与者也会commit。

5.Paxos岛的故事来对应ZooKeeper

(1)Paxos岛的故事背景

(2)Paxos岛的故事运作

(3)Paxos岛的故事与ZooKeeper对应关系

(4)Paxos岛的故事的总统

先说Paxos，它是一个基于消息传递的一致性算法。Chubby和ZooKeeper都是基于Paxos的理论来实现的，Paxos还被认为是到目前为止唯一的分布式一致性算法，其它的算法都是Paxos的改进或简化。

但是Paxos有一个前提：没有拜占庭将军问题。就是Paxos只有在一个可信的计算环境中才能成立，这个环境是不会被入侵所破坏的。

(1)Paxos岛的故事背景

有一个叫做Paxos小岛(对应zk集群)，上面住了一批居民(对应zk的Client)。岛上面的事情由一些特殊的人决定，他们叫做议员(对应zk的Server)。议员(对应zk的Server)的总数是确定的，不能更改。

岛上的居民(对应zk的Client)每次进行事情变更都需要通过一个提议(Proposal)。每个提议都有一个编号(PID，对应zk的ZXID)。这个编号是一直增长的，不能倒退。每个提议都要超过半数议员同意才能生效。因为如果全部通过就是强一致性，会破坏可用性。

每个议员(zk的Server)只会同意大于当前编号(zk的ZXID)的提议(Proposal)，包括已生效和未生效的(分布式节点要排除由于网络延迟而晚收到的消息)。如果议员收到小于等于当前编号的提议，他会拒绝，并告知对方(对应zk的Client)：你的提议已经有人提过了(保证数据的版本性)。当前编号指的是每个议员在记事本上记录的编号，他会不断更新该编号。整个会议不能保证所有议员记事本上的编号总是相同的，因为网络延迟可能半数人已通过第10版本了，部分人还停留在第9版本。

现在会议有一个目标：保证所有议员(zk的Server)对提议(Proposal)都能达成一致的看法(完成所有数据的同步)。

(2)Paxos岛的故事运作

好，现在会议开始运作，所有议员一开始记事本上面记录的编号都是0。

说明一：有一个议员收到了居民的一个提议：将电费设定为1元/度。他首先看一下记事本，发现当前提议编号是0，则他的这个提议编号就是1。于是他给所有议员发起提议：1号提议，设定电费1元/度。

说明二：其他议员收到消息以后查了一下记事本，发现当前提议编号是0。所以接收到的这个提议是可以接受的，于是记录下这个提议并回复：我接受你的1号提议，同时在记事本上记录：当前提议编号为1。

说明三：发起提议的议员收到了超过半数的回复。于是他立即给所有人发通知：1号提议生效！收到该通知的议员会修改他的记事本，将1号提议由记录改成正式的法令。当有居民问他电费多少时，他会查看并告诉对方：1元/度。

上面这个议员发出第一个提议的阶段其实隐含了两阶段提交的概念，总的来说，过半通过 + 两阶段提交，可以非常好地解决消息的传递。

说明四：冲突的解决。假设总共有三个议员S1、S2、S3，S1和S2同时发起了一个提议：1号提议，设定电费。但S1想设为1元/度，S2想设为2元/度。此时S1和S2的提议各有一票了。结果S3先收到了S1的提议，于是他做了和前面同样的操作。紧接着他又收到了S2的提议，结果他一查记事本，发现这个提议的编号小于等于我的当前编号1，于是拒绝了这个提议：对不起，这个提议先前提过了。因此S2的提议被拒绝，S1的提议被S1和S3同意。所以S1可以正式发布提议：1号提议生效。S2向S1或S3打听并更新1号法令的内容，之后可选择继续发起2号提议。

至此，Paxos的核心已通过故事介绍完毕。

(3)Paxos岛的故事与ZooKeeper对应关系

小岛——ZooKeeper Server Cluster
议员——ZooKeeper Server
居民——ZooKeeper Client
总统——ZooKeeper Server Leader
提议(Proposal)——ZNode Change(Create/Delete/SetData)
提议编号(PID)——ZXID(ZooKeeper Transaction Id)
正式法令——所有ZNode及其数据

Paxos岛上的议员应该是人人平等，而ZooKeeper Server有一个Leader的概念。如果议员人人平等，在某种情况下会由于提议的冲突而产生一个活锁。所谓活锁意思是大家都没有死都在动，但一直解决不了冲突问题。

Lamport在《The Part-Time Parliament》中阐述了活锁问题并给出了方案：在所有议员中设立一个总统，只有总统有权发出提议。如果议员有自己的提议，必须发给总统并由总统来提出。

(4)Paxos岛的故事的总统

又一个问题产生了，总统怎么选出来的？ZooKeeper是如何选出Leader的？

现在假设总统已经选好了，下面看看ZooKeeper Server是怎么实施的。

情况一：对应zk的客户端读数据。居民甲到某个议员那里询问(Get)某条法令的情况(ZNode的数据)，议员毫不犹豫的拿出他的记事本，查阅法令并告诉他结果。同时该议员会向居民甲声明：我的数据不一定是最新的，如果想要最新的数据，那么需要等一会，等我找总统Sync一下再告诉你。

情况二：对应zk的客户端进行数据修改，修改权交由Leader处理。居民乙到某个议员那里要求政府归还(Set)欠他的一万元钱(ZNode的数据)。议员让他在办公室等着，自己将问题反映给了总统。总统询问所有议员的意见，多数议员表示欠居民的钱一定要还。于是总统发表声明，从国库中拿出一万元还债，国库由100万变成99万。居民乙拿到钱回去了。

情况三：ZooKeeper Server的Leader挂了。总统突然挂了，议员接二连三的发现联系不上总统，于是各自发表声明，推选新的总统。总统大选期间政府停业，拒绝居民的请求。Leader选举的过程中，节点不提供对外服务。Leader挂了，影响写操作。