ZooKeeper是什么

Posted 2021-06-26 小坏蛋至尊宝

ZooKeeper是什么？

ZooKeeper是⼀个分布式的，开放源码的分布式应⽤程序协调服务，是Google的Chubby⼀个开源的实现，它是集群的管理者，

监视着集群中各个节点的状态根据节点提交的反馈进⾏下⼀步合理操作。最终，将简单易⽤的接⼝和性能⾼效、功能稳定的系统

提供给⽤⼾。

客⼾端的读请求可以被集群中的任意⼀台机器处理，如果读请求在节点上注册了监听器，这个监听器也是由所连接的zookeeper

机器来处理。对于写请求，这些请求会同时发给其他zookeeper机器并且达成⼀致后，请求才会返回成功。因此，随着

zookeeper的集群机器增多，读请求的吞吐会提⾼但是写请求的吞吐会下降。

有序性是zookeeper中⾮常重要的⼀个特性，所有的更新都是全局有序的，每个更新都有⼀个唯⼀的时间戳，这个时间戳称为

zxid（Zookeeper Transaction Id）。⽽读请求只会相对于更新有序，也就是读请求的返回结果中会带有这个zookeeper最新的

 

所以从本质来说， ZooKeeper就是⼀个第三⽅，也称中间⼈，它搭建了⼀个平台，让所有其它进程通过它来进⾏间 接的交流。

.ZooKeeper提供了什么

1、⽂件系统

2、通知机制

ZooKeeper的数据模型

 

计算机其实就是⽤来处理或存储数据的，运⾏在它上⾯的软件⼤都也是如此。zookeeper作为多进程的协调者，肯

定是跑不了了。

存储数据和摆放物品是⼀样的，不能随意乱扔，这样既占地⽅，⼜不好看，也难寻找。所以必须得有⼀定的层次结构。

这就是计算机的专业课数据结构了。

最简单的数据结构就是数组或链表了。它们被称为线性表，是⼀维的，具有线性关系，即前后顺序，优点是简单，缺点

是功能不够强⼤。

然后就是树了，可以认为它是两维的，左右是兄弟关系，上下是⽗⼦关系，因此具有从属关系。它是⼀个功能与复杂 度兼顾的结构。现实⽣活中的各类组织架构⼤都是树形的。

再复杂的就是图了，它是⽹状结构，可以认为是多维的，由于任何节点都可以连通，因此它表达⼀种多边关系。虽功

能强⼤但也很复杂。现实中的铁路⽹和⼈际关系⽹⼤都是⽹状的。

当然，这是三⼤类数据结构，每⼀类中⼜可以分为很多种。⽐如树就有很多种变体，虽然都叫树，但有的差别还是很

⼤的。

ZooKeeper选择了树作为⾃⼰存储数据的结构，其实它和⽂件系统也⾮常相似，如下图：

谈到数据就离不开增、删、改、查，对应树来说， 增就是添加新的节点到树中，删就是从树中删除某个节点，改就是修 改树中某个节点上存放的数据，查就是找到树中某个节点读取它上⾯存放的数据。

说⽩了就是树形表⽰的是⼀种结构，真正的数据是在节点上放着呢，叶⼦节点或⾮叶⼦节点都可以。

ZooKeeper 的能力

我们从最常⻅的场景⼊⼿，从宏观上了解下zookeeper是如何使⽤的，以及它应该具备哪些能⼒。

场景⼀： 

有两个应⽤程序进程A和B，A先处理数据，处理完后通知B，B再接着处理。我们应该如何利⽤zookeeper来完成这 个呢？⼀起来分析⼀下。

⾸先，进程A连接上zookeeper，在上⾯创建⼀个节点来表⽰⾃⼰的存在，假设节点名称就叫foo吧。

然后在节点上设置⼀个数据叫 doing ，表⽰⾃⼰正在处理数据。过了⼀会处理完后，把节点上的数据更新为 done 。

这样进程A的⼯作就算完了。可是这怎么去影响到进程B呢？我们知道zookeeper完成的是 进程间的间接交流，即进 程之间是不碰⾯的。 因此只能借助于这个树形⾥的节点。 进程B也要连上zookeeper，然后找到foo节点，看好它上⾯的数据是否由doing变成了done，如果是⾃⼰就开始

处理数据，如果否那就继续等着。

问题是进程B不能⾃⼰⽼盯着foo节点啊，这样太累了，伤神，况且它还要做其它事情呢。那这个事情应该由谁来做 呢？很显然是zookeeper嘛。

于是进程B就对zookeeper说，你给我盯着foo节点，什么时候变成done了通知我⼀声，我就开⼲了。

因此， zookeeper需要具有盯梢能⼒和通知其它进程的能⼒ 。这在zookeeper中对应⼀个专业术语，叫 Wat ch 。

Wat ch的作⽤和⽤法与上⾯描述的⼀样。就是进程B找到foo节点，在上⾯放⼀个Wat ch就可以了。

这样zookeeper就知道进程B对foo节点⽐较关注，于是zookeeper就盯着foo节点，⼀有⻛吹草动，⻢上通知进程B。

 

需要注意的是， 这个Wat ch是⼀次性的，即只能使⽤⼀次。也就是说，zookeeper通知过进程B之后，Wat ch就被⽤ 掉了，以后就不会再通知了。

如果进程B还需要被通知怎么办？很简单，那就在foo节点上 再放⼀个新的Wat ch即可。如此这般下去，就可以保证 ⼀直被通知了。

我想这个Wat ch之所以被设计成⼀次性的，就是zookeeper不想让⾃⼰太累。睁着⼀双⼤眼，盯的东西太多太久的 话，确实很累。

另外，zookeeper在通知进程B的时候，是可以把foo节点存放的数据⼀并发送过去的。

细⼼的朋友可能已经发现，zookeeper可以主动向进程B发通知或推数据，说明zookeeper和进程B之间的连接需 要被⼀直保持。

因为进程B的位置⽐较随意，本来就是业务进程嘛。⼀旦连接断开，就像断了线的⻛筝，zookeeper再也⽆法找到进 程B了。

不过zookeeper的位置是固定的，⼀旦连接断掉后，进程B可以再次向zookeeper发起连接请求，如果断开的时间

⾜够短的话，进程B应该还可以在zookeeper上找回⾃⼰曾经拥有的⼀切。

这就涉及到了会话，因此zookeeper还要有⼀定的会话延续能⼒，⽅便在断开时间不⻓的时候找回原来的会话。

因此zookeeper应该有， 监视节点、通知进程、保持⻓连接，会话延续 等这样的能⼒。

场景⼆： 

有时为了⾼可⽤或⾼性能，通常会把⼀个应⽤程序运⾏多份。假如运⾏了四份，那就是四个进程，分别是A、B、C、D。

当⼀个调⽤过来时，发现A、B、C、D都可以调，那就根据配置的负载均衡策略选出⼀个调⽤即可。

假设D进程所在的机器不幸掉电了，其实就是D挂了，那么此时再来⼀个调⽤的话，会发现只有A、B、C可以调，D⾃动 就不存在了。

这其实就是Dubbo功能的⼀部分，那该如何基于zookeeper实现呢？照例⼀起分析下吧。

由于zookeeper是基于树形的数据结构，所以还是要拿节点说事。当进程A启动时，需要连接上zookeeper，然后 创建⼀个节点来代表⾃⼰。

节点名称和节点上存放的数据可以根据实际情况来定，⾄少要包括该进程运⾏的IP和端⼝信息。进程B、C、D也做同 样的事情。

如果让进程A、B、C、D的节点都位于同⼀个⽗节点下⾯，这样当⼀个调⽤过来后，只要找到这个⽗节点，读出它的所 有⼦节点，就得到了所有可调⽤的进程信息。

如果某⼀时刻，进程D挂掉了，那么⽗节点下⾯进程D对应的那个节点应该会⾃动被zookeeper删除。这在 zookeeper⾥有个专业术语，叫 临时节点 （ Ephemeral Node ）。那么与之对应的⾃然就是永久节点了。

其实⼯作过程是这样的，业务进程启动后与zookeeper建⽴连接，然后在zookeeper⾥创建临时节点并写⼊⾃⼰ 的相关信息。接着通过周期性的⼼跳和zookeeper保持住连接。

⼀旦业务进程挂掉，zookeeper将接受不到⼼跳了，那么在超过⼀定的时间后，zookeeper将会删除与之对应的临 时节点，表⽰这个业务进程不再可⽤了。

Dubbo的做法是将接⼝名称和IP端⼝信息和我们设置的信息整合成⼀个类似URL的字符串，然后以这个字符串作 为名称来创建临时节点。

临时节点不允许有孩⼦节点，只有永久节点才可以。

 

.

Zookeeper⽂件系统 3

Zookeeper提供⼀个多层级的节点命名空间（节点称为znode）。与⽂件系统不同的是，这些节点都可以设置关联的数据，⽽⽂ 件系统中只有⽂件节点可以存放数据⽽⽬录节点不⾏。Zookeeper为了保证⾼吞吐和低延迟，在内存中维护了这个树状的⽬录结 构，这种特性使得Zookeeper不能⽤于存放⼤量的数据，每个节点的存放数据上限为1M。

4.四种类型的znode 4

1、PERSISTENT-持久化⽬录节点 

客⼾端与zookeeper断开连接后，该节点依旧存在

2、PERSISTENT_SEQUENTIAL-持久化顺序编号⽬录节点

客⼾端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进⾏顺序编号

3、EPHEMERAL-临时⽬录节点

客⼾端与zookeeper断开连接后，该节点被删除

4、EPHEMERAL_SEQUENTIAL-临时顺序编号⽬录节点

客⼾端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进⾏顺序编号

5.Zookeeper通知机制

client端会对某个znode建⽴⼀个watcher事件，当该znode发⽣变化时，这些client会收到zk的通知，然后client可以根据

znode变化来做出业务上的改变等。

6.Zookeeper做了什么？

命名服务

配置管理

集群管理

分布式锁

队列管理

7.zk的命名服务（⽂件系统）

命名服务是指通过指定的名字来获取资源或者服务的地址，利⽤zk创建⼀个全局的路径，即是唯⼀的路径，这个路径就可以作为

⼀个名字，指向集群中的集群，提供的服务的地址，或者⼀个远程的对象等等。

8.zk的配置管理（⽂件系统、通知机制）

程序分布式的部署在不同的机器上，将程序的配置信息放在zk的znode下，当有配置发⽣改变时，也就是znode发⽣变化时，可

以通过改变zk中某个⽬录节点的内容，利⽤watcher通知给各个客⼾端，从⽽更改配置。

9.Zookeeper集群管理（⽂件系统、通知机制）

所谓集群管理⽆在乎两点：是否有机器退出和加⼊、选举master。

对于第⼀点，所有机器约定在⽗⽬录下创建临时⽬录节点，然后监听⽗⽬录节点的⼦节点变化消息。⼀旦有机器挂掉，该机器与

zookeeper的连接断开，其所创建的临时⽬录节点被删除，所有其他机器都收到通知：某个兄弟⽬录被删除，于是，所有⼈都知

道：它上船了。

新机器加⼊也是类似，所有机器收到通知：新兄弟⽬录加⼊，highcount⼜有了，对于第⼆点，我们稍微改变⼀下，所有机器创

建临时顺序编号⽬录节点，每次选取编号最⼩的机器作为master就好。

10.Zookeeper分布式锁（⽂件系统、通知机制）

有了zookeeper的⼀致性⽂件系统，锁的问题变得容易。锁服务可以分为两类，⼀个是保持独占，另⼀个是控制时序。

对于第⼀类，我们将zookeeper上的⼀个znode看作是⼀把锁，通过createznode的⽅式来实现。所有客⼾端都去创建

/distribute_lock 节点，最终成功创建的那个客⼾端也即拥有了这把锁。⽤完删除掉⾃⼰创建的distribute_lock 节点就释放出

锁。

对于第⼆类， /distribute_lock 已经预先存在，所有客⼾端在它下⾯创建临时顺序编号⽬录节点，和选master⼀样，编号最⼩的

获得锁，⽤完删除，依次⽅便。

11.获取分布式锁的流程

在获取分布式锁的时候在locker节点下创建临时顺序节点，释放锁的时候删除该临时节点。客⼾端调⽤createNode⽅法在locker

下创建临时顺序节点，然后调⽤getChildren(“locker”)来获取locker下⾯的所有⼦节点，注意此时不⽤设置任何Watcher。

客⼾端获取到所有的⼦节点path之后，如果发现⾃⼰创建的节点在所有创建的⼦节点序号最⼩，那么就认为该客⼾端获取到了

锁。如果发现⾃⼰创建的节点并⾮locker所有⼦节点中最⼩的，说明⾃⼰还没有获取到锁，此时客⼾端需要找到⽐⾃⼰⼩的那个

节点，然后对其调⽤exist()⽅法，同时对其注册事件监听器。

之后，让这个被关注的节点删除，则客⼾端的Watcher会收到相应通知，此时再次判断⾃⼰创建的节点是否是locker⼦节点中序

号最⼩的，如果是则获取到了锁，如果不是则重复以上步骤继续获取到⽐⾃⼰⼩的⼀个节点并注册监听。当前这个过程中还需要

许多的逻辑判断。

代码的实现主要是基于互斥锁，获取分布式锁的重点逻辑在于BaseDistributedLock，实现了基于Zookeeper实现分布式锁的细

节。

12.Zookeeper队列管理（⽂件系统、通知机制）

两种类型的队列：

同步队列，当⼀个队列的成员都聚⻬时，这个队列才可⽤，否则⼀直等待所有成员到达。

队列按照 FIFO ⽅式进⾏⼊队和出队操作。

第⼀类，在约定⽬录下创建临时⽬录节点，监听节点数⽬是否是我们要求的数⽬。

第⼆类，和分布式锁服务中的控制时序场景基本原理⼀致，⼊列有编号，出列按编号。在特定的⽬录下创建

PERSISTENT_SEQUENTIAL节点，创建成功时Watcher通知等待的队列，队列删除序列号最⼩的节点⽤以消费。

此场景下Zookeeper的znode⽤于消息存储，znode存储的数据就是消息队列中的消息内容，SEQUENTIAL序列号就是消息的编

号，按序取出即可。由于创建的节点是持久化的，所以不必担⼼队列消息的丢失问题。

13.Zookeeper数据复制

Zookeeper作为⼀个集群提供⼀致的数据服务，⾃然，它要在所有机器间做数据复制。数据复制的好处：

容错：⼀个节点出错，不致于让整个系统停⽌⼯作，别的节点可以接管它的⼯作；

提⾼系统的扩展能⼒ ：把负载分布到多个节点上，或者增加节点来提⾼系统的负载能⼒；

提⾼性能：让客⼾端本地访问就近的节点，提⾼⽤⼾访问速度。

从客⼾端读写访问的透明度来看，数据复制集群系统分下⾯两种：

写主(WriteMaster) ：对数据的修改提交给指定的节点。读⽆此限制，可以读取任何⼀个节点。这种情况下客⼾端需要对读

与写进⾏区别，俗称读写分离；

写任意(Write Any)：对数据的修改可提交给任意的节点，跟读⼀样。这种情况下，客⼾端对集群节点的⻆⾊与变化透明。

对zookeeper来说，它采⽤的⽅式是写任意。通过增加机器，它的读吞吐能⼒和响应能⼒扩展性⾮常好，⽽写，随着机器的增多

吞吐能⼒肯定下降（这也是它建⽴observer的原因），⽽响应能⼒则取决于具体实现⽅式，是延迟复制保持最终⼀致性，还是⽴

即复制快速响应。

14.Zookeeper⼯作原理

Zookeeper 的核⼼是原⼦⼴播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。

Zab协议有两种模式，它们分别是恢复模式（选主）和⼴播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进⼊了恢复

模式，当领导者被选举出来，且⼤多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和

Server具有相同的系统状态。

15.zookeeper是如何保证事务的顺序⼀致性的？

zookeeper采⽤了递增的事务Id来标识，所有的proposal（提议）都在被提出的时候加上了zxid，zxid实际上是⼀个64位的数

字，⾼32位是epoch（时期; 纪元; 世; 新时代）⽤来标识leader是否发⽣改变，如果有新的leader产⽣出来，epoch会⾃增，低

32位⽤来递增计数。当新产⽣proposal的时候，会依据数据库的两阶段过程，⾸先会向其他的server发出事务执⾏请求，如果超

过半数的机器都能执⾏并且能够成功，那么就会开始执⾏。

16.Zookeeper 下 Server⼯作状态

每个Server在⼯作过程中有三种状态：

LOOKING：当前Server不知道leader是谁，正在搜寻

LEADING：当前Server即为选举出来的leader

FOLLOWING：leader已经选举出来，当前Server与之同步

17.zookeeper是如何选取主leader的？

当leader崩溃或者leader失去⼤多数的follower，这时zk进⼊恢复模式，恢复模式需要重新选举出⼀个新的leader，让所有的

Server都恢复到⼀个正确的状态。Zk的选举算法有两种：⼀种是基于basic paxos实现的，另外⼀种是基于fast paxos算法实现

的。系统默认的选举算法为fast paxos。

1、Zookeeper选主流程(basic paxos)

（1）选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进⾏统计，并选出推荐的Server；

（2）选举线程⾸先向所有Server发起⼀次询问(包括⾃⼰)；

（3）选举线程收到回复后，验证是否是⾃⼰发起的询问(验证zxid是否⼀致)，然后获取对⽅的id(myid)，并存储到当前询问对象

列表中，最后获取对⽅提议的leader相关信息(id,zxid)，并将这些信息存储到当次选举的投票记录表中；

（4）收到所有Server回复以后，就计算出zxid最⼤的那个Server，并将这个Server相关信息设置成下⼀次要投票的Server；

（5）线程将当前zxid最⼤的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得n/2 + 1的Server票数，设置

当前推荐的leader为获胜的Server，将根据获胜的Server相关信息设置⾃⼰的状态，否则，继续这个过程，直到leader被选举出

来。通过流程分析我们可以得出：要使Leader获得多数Server的⽀持，则Server总数必须是奇数2n+1，且存活的Server的数⽬

不得少于n+1. 每个Server启动后都会重复以上流程。在恢复模式下，如果是刚从崩溃状态恢复的或者刚启动的server还会从磁盘

快照中恢复数据和会话信息，zk会记录事务⽇志并定期进⾏快照，⽅便在恢复时进⾏状态恢复。

2、Zookeeper选主流程(basic paxos)

fast paxos流程是在选举过程中，某Server⾸先向所有Server提议⾃⼰要成为leader，当其它Server收到提议以后，解决epoch

和 zxid的冲突，并接受对⽅的提议，然后向对⽅发送接受提议完成的消息，重复这个流程，最后⼀定能选举出Leader。

18.Zookeeper同步流程

选完Leader以后，zk就进⼊状态同步过程。

Leader等待server连接；

Follower连接leader，将最⼤的zxid发送给leader；

Leader根据follower的zxid确定同步点；

完成同步后通知follower 已经成为uptodate状态；

Follower收到uptodate消息后，⼜可以重新接受client的请求进⾏服务了。

19.分布式通知和协调

对于系统调度来说：操作⼈员发送通知实际是通过控制台改变某个节点的状态，然后zk将这些变化发送给注册了这个节点的

watcher的所有客⼾端。

对于执⾏情况汇报：每个⼯作进程都在某个⽬录下创建⼀个临时节点。并携带⼯作的进度数据，这样汇总的进程可以监控⽬录⼦

节点的变化获得⼯作进度的实时的全局情况。

20.机器中为什么会有leader？

在分布式环境中，有些业务逻辑只需要集群中的某⼀台机器进⾏执⾏，其他的机器可以共享这个结果，这样可以⼤⼤减少重复计

算，提⾼性能，于是就需要进⾏leader选举。

21.zk节点宕机如何处理？

Zookeeper本⾝也是集群，推荐配置不少于3个服务器。Zookeeper⾃⾝也要保证当⼀个节点宕机时，其他节点会继续提供服

务。

如果是⼀个Follower宕机，还有2台服务器提供访问，因为Zookeeper上的数据是有多个副本的，数据并不会丢失；

如果是⼀个Leader宕机，Zookeeper会选举出新的Leader。

ZK集群的机制是只要超过半数的节点正常，集群就能正常提供服务。只有在ZK节点挂得太多，只剩⼀半或不到⼀半节点能⼯作，

集群才失效。

所以

3个节点的cluster可以挂掉1个节点(leader可以得到2票>1.5)

2个节点的cluster就不能挂掉任何1个节点了(leader可以得到1票<=1)

22.zookeeper负载均衡和nginx负载均衡区别

zk的负载均衡是可以调控，nginx只是能调权重，其他需要可控的都需要⾃⼰写插件；但是nginx的吞吐量⽐zk⼤很多，应该说按

业务选择⽤哪种⽅式。

23.zookeeper watch机制

Watch机制官⽅声明：⼀个Watch事件是⼀个⼀次性的触发器，当被设置了Watch的数据发⽣了改变的时候，则服务器将这个改

变发送给设置了Watch的客⼾端，以便通知它们。

Zookeeper机制的特点：

1、⼀次性触发数据发⽣改变时，⼀个watcher event会被发送到client，但是client只会收到⼀次这样的信息。

2、watcher event异步发送watcher的通知事件从server发送到client是异步的，这就存在⼀个问题，不同的客⼾端和服务器之

间通过socket进⾏通信，由于⽹络延迟或其他因素导致客⼾端在不通的时刻监听到事件，由于Zookeeper本⾝提供了ordering

guarantee，即客⼾端监听事件后，才会感知它所监视znode发⽣了变化。所以我们使⽤Zookeeper不能期望能够监控到节点每

次的变化。Zookeeper只能保证最终的⼀致性，⽽⽆法保证强⼀致性。

3、数据监视Zookeeper有数据监视和⼦数据监视getdata() and exists()设置数据监视，getchildren()设置了⼦节点监视。

4、注册watcher getData、exists、getChildren

5、触发watcher create、delete、setData

6、setData()会触发znode上设置的data watch（如果set成功的话）。⼀个成功的create() 操作会触发被创建的znode上的数

据watch，以及其⽗节点上的child watch。⽽⼀个成功的delete()操作将会同时触发⼀个znode的data watch和child

watch（因为这样就没有⼦节点了），同时也会触发其⽗节点的child watch。

7、当⼀个客⼾端连接到⼀个新的服务器上时，watch将会被以任意会话事件触发。当与⼀个服务器失去连接的时候，是⽆法接收

到watch的。⽽当client重新连接时，如果需要的话，所有先前注册过的watch，都会被重新注册。通常这是完全透明的。只有在

⼀个特殊情况下，watch可能会丢失：对于⼀个未创建的znode的exist watch，如果在客⼾端断开连接期间被创建了，并且随后

在客⼾端连接上之前⼜删除了，这种情况下，这个watch事件可能会被丢失。

8、Watch是轻量级的，其实就是本地JVM的Callback，服务器端只是存了是否有设置了Watcher的布尔类型。

Zookeeper：分布式架构详解、分布式技术详解、分布式事务

⼀、分布式架构详解

1、分布式发展历程

1.1 单点集中式

特点：App、DB、FileServer都部署在⼀台机器上。并且访问请求量较少

1.2 应⽤服务和数据服务拆分

特点：App、DB、FileServer分别部署在独⽴服务器上。并且访问请求量较少

1.3 使⽤缓存改善性能

特点：数据库中频繁访问的数据存储在缓存服务器中，减少数据库的访问次数，降低数据库的压⼒

1.4 应⽤服务器集群

特点：多台应⽤服务器通过负载均衡同时对外提供服务，解决单台服务器处理能⼒上限的问题

1.5 数据库读写分离

特点：数据库进⾏读写分离（主从）设计，解决数据库的处理压⼒

1.6 反向代理和CDN加速

特点：采⽤反向代理和CDN加快系统的访问速度

1.7 分布式⽂件系统和分布式数据库

特点：数据库采⽤分布式数据库，⽂件系统采⽤分布式⽂件系统

随着业务的发展，最终数据库读写分离也将⽆法满⾜需求，需要采⽤分布式数据库和分布式⽂件系统来⽀撑

分布式数据库是数据库拆分后的最后⽅法，只有在单表规模⾮常庞⼤的时候才使⽤，更常⽤的数据库拆分⼿段是业务分库，将不

同业务的数据库部署在不同的机器上

⼆、 分布式技术详解

1. 并发性

2. 分布性

⼤任务拆分成多个任务部署到多台机器上对外提供服务

3. 缺乏全局时钟

时间要统⼀

4. 对等性

⼀个服务部署在多台机器上是⼀样的，⽆任何差别

5. 故障肯定会发⽣

硬盘坏了 CPU烧了....

三、分布式事务

1. ACID

原⼦性（Atomicity）：⼀个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。

事务在执⾏过程中发⽣错误，会被恢复（Rollback）到事务开始前的状态，就像这个事务从来没有执⾏过⼀样。

⼀致性（Consistency）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表⽰写⼊的资料必须完全符合所有

的预设规则，这包含资料的精确度、串联性以及后续数据库可以⾃发性地完成预定的⼯作。

⽐如A有500元，B有300元，A向B转账100，⽆论怎么样，A和B的总和总是800元

隔离性（Isolation）：数据库允许多个并发事务同时对其数据进⾏读写和修改的能⼒，隔离性可以防⽌多个事务并发执⾏时由于

交叉执⾏⽽导致数据的不⼀致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read

committed）、可重复读（repeatable read）和串⾏化（Serializable）。

持久性（Durability）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

2. 2P/3P

2P= Two Phase commit ⼆段提交（RDBMS（关系型数据库管理系统）经常就是这种机制，保证强⼀致性）

3P= Three Phase commit 三段提交

说明：2P/3P是为了保证事务的ACID（原⼦性、⼀致性、隔离性、持久性）

2.1 2P的两个阶段

阶段1：提交事务请求（投票阶段）询问是否可以提交事务

阶段2：执⾏事务提交（commit、rollback） 真正的提交事务

2.2 3P的三个阶段

阶段1：是否提交-询问是否可以做事务提交

阶段2：预先提交-预先提交事务

阶段3：执⾏事务提交（commit、rollback）真正的提交事务

说明：3P把2P的阶段⼀拆分成了前⾯两个阶段

3. CAP理论

⼀致性（Consistency）：分布式数据库的数据保持⼀致

可⽤性（Availability）：任何⼀个节点挂了，其他节点可以继续对外提供服务

分区容错性（⽹络分区）Partition tolerance：⼀个数据库所在的机器坏了，如硬盘坏了，数据丢失了，可以新增⼀台机器，然

后从其他正常的机器把备份的数据同步过来

CAP理论的特点：CAP只能满⾜其中2条

CA(放弃P)：将所有的数据放在⼀个节点。满⾜⼀致性、可⽤性。

AP(放弃C)：放弃强⼀致性，⽤最终⼀致性来保证。

CP(放弃A)：⼀旦系统遇⻅故障，受到影响的服务器需要等待⼀段时间，在恢复期间⽆法对外提供服务。

举例说明CAP理论：

有3台机器分别有3个数据库分别有两张表,数据都是⼀样的

Machine1-db1-tbl_person、tbl_order

Machine2-db2-tbl_person、tbl_order

Machine3-db3-tbl_person、tbl_order

1）当向machine1的db1的表tbl_person、tbl_order插⼊数数据时，同时要把插⼊的数据同步到machine2、machine3，这就

是⼀致性

2）当其中的⼀台机器宕机了，可以继续对外提供服务，把宕机的机器重新启动起来可以继续服务，这就是可⽤性

3）当machine1的机器坏了，数据全部丢失了，不会有任何问题，因为machine2和machine3上还有数据，重新加⼀台机器

machine4，把machine2和machine3其中⼀台机器的备份数据同步过来就可以了，这就是分区容错性

4. BASE理论

基本可⽤（bascially available）、软状态（soft state）、最终⼀致性（Eventually consistent）

基本可⽤：在分布式系统出现故障，允许损失部分可⽤性（服务降级、⻚⾯降级）

软状态：允许分布式系统出现中间状态。⽽且中间状态不影响系统的可⽤性。

1、这⾥的中间状态是指不同的data replication之间的数据更新可以出现延时的最终⼀致性

2、如CAP理论⾥⾯的⽰例，当向machine1的db1的表tbl_person、tbl_order插⼊数数据时，同时要把插⼊的数据同步到

machine2、machine3，当machine3的⽹络有问题时，同步失败，但是过⼀会⽹络恢复了就同步成功了，这个同步失败的状态

就称为软状态，因为最终还是同步成功了。

最终⼀致性：data replications经过⼀段时间达到⼀致性。

5. Paxos算法

5.1 介绍Paxos算法之前我们先来看⼀个⼩故事

以上是关于ZooKeeper是什么的主要内容，如果未能解决你的问题，请参考以下文章

Zookeeper - 什么是Zookeeper,以及zookeeper的安装

什么是ZooKeeper？

什么是Zookeeper，Zookeeper的作用是什么，在Hadoop及hbase中具体作用是什么？

zookeeper能做什么？

如果有人问你ZooKeeper是什么，就把这篇文章发给他。

什么是ZooKeeper？