ZooKeeper知识点都有哪些

本文向您展示了ZooKeeper的知识点。内容简洁易懂。它一定会让你的眼睛发光。希望通过这篇文章的详细介绍，你能有所收获。

一、 从集中式到分布式

1. 集中式

集中式特点：不考虑网络分区、停机和协作。但是很贵。

2. 分布式

分布式:它由通过网络通信的多台机器、多节点机器、分布式和频繁故障组成。

原因：网络问题，多台机器的网络通讯容易超时，中间可能会断导致分区。

网络分区：俗称脑裂。

网络三态问题：要么连接成功，要么失败，要么超时。

所以分发主要是网络和机器的问题，最大的问题是网络问题。

数据库等事务

原子：要么成功，要么失败；

一致性：如有异常数据，仍为原数据。

隔离：每个会话彼此独立。

持久性：即提交的数据永久存储在磁盘上，不会丢失。

00-1010一致性：多台机器有相同的副本。

可用性：在正确的时间响应客户。

分区容错：网络分区不能发生。

00-1010分发的主要问题是网络，所以我们优先考虑分布式网络，然后权衡一致性和可用性。此时提出BASE是CAP一致性和可用性的平衡结果。

BASE基本可用，最终保持一致。

最终一致性:当你提交一台机器时，其他机器最终会同步你提交给自己的机器。

00-1010主控机器称为协调器，副本机器称为参与者。

00-1010，两个阶段，交易提交和交易执行。

提交事务

1).要求

2).执行初始化(执行提交)

执行交易

2PC故障情况

单机

1.如果协调器失败，将由一个备份协调器接管，并查询参与者的当前实施状态，然后继续。

2.如果参与者失败，协调器将等待它重新启动，然后继续。

在这两种情况下，只会有阻塞,不会有不一致。

同时故障：

协调者和参与者同时失败。

例如，有机器1、2、3、4。4是协调者，1、2和3是参与者。

4、2提交交易后失败，3此时也失败。注意这里是3，没有提交交易数据。现在备用协调器已经开始询问参与者，因为3已经死了，并且从来不知道它处于什么状态(它是否已经接受了提交的事务，或者它是否可以被执行)。

面对这种情况，让1，2返回停止事务，3恢复后直接停止事务回滚，不考虑状态，从而保证一致性。

这就是2PC的漏洞。当它同时出现故障时，将全部回滚，这既低效又昂贵。

劣势

当协调者出错，参与者出错时，事务执行的完整性无法分两个阶段得到保证。

考虑协调器发送一条提交消息，然后关闭，并且接收该消息的唯一参与者也关闭。即使协调人通过选举协议产生了新的协调人，该交易的状态也是不确定的，没有人知道交易是否已经提交。

3. ACID

2PC只考虑了单机故障的情况，没有同时考虑协调者和参与者故障的情况。3PC是2PC漏洞的补充协议。它将2PC中的提交事务请求分成两部分，并添加一个状态(准备阶段)。即使两个故障同时出现故障，也不会被阻塞，一致性得到保证。

交易阶段(can阶段)

事务准备阶段(预)(包括执行提交)

执行事务阶段(提交)(更改状态)

以下示例分析：

1.4是协调者，1、2和3是参与者。当新闻节点、协调者4和参与者3同时挂断时。这时备用协调器启动，查询1和2的状态，都处于can阶段，直接回滚，代价是回滚。3.当您重新启动发现您是的阶段时，可以以回滚为代价，执行回滚并停止事务。这就保证了三个节点的数据一致性。3PC对应2PC，降低回滚成本。

当所有三名参与者都进入per准备阶段时，它表明他们都收到了提交查询并投票(意味着他们都收到了数据)，然后协调者4和参与者3突然死亡。在协调待命后，其他参与者被询问他们的状态。乍一看，他们都到了前期，说明他们已经收到了包括死者3在内的数据。因为他在进入准备阶段之前就已经投票了，所以他要求大家提交。3重启后，我看了日志，发现我在准备阶段已经死了，可以提交了，保证了数据的一致性。

00-1010，有个小岛叫帕克斯。他们的每一项决定都必须通过提案，然后其中一半才能生效。决策的每个提案都有唯一的全局号，只能自增，不能倒推。铌

sp;
何为通过：就是提议的id好要大于议员手记录的最大的id

第一阶段：提议者发起提议给每个议员，然后等议员反馈同意或不同意。

第二阶段：如果半数以上同意了，则执行事务，否则不执行。

如果半数以上同意了，这个议题就通过，然后提议者就命令剩下的议员同步自己的数据，并修改手上的最大id好。

问题：在分布式中并发是常见的，例如现在有提议者p1，p2 
提议者同时提出一个提议，这个时候他们手上的id就有可能是一样，p1的id是3，p2的id也是3。当p1提议给议员（假设议员手上的id是2），现在议员先同意了p1，p2来访问这个议员，议员告诉他已经同意了议题id是3，p2的id是3不同意。然后p2回去加大自己的id重新请求，议员这时同意了他。p1收到半数同意准备去通知他们来更新id同步数据，可是发现议员们的id比自己的大了，然后p1有加大id。这种极端情况，导致死锁了。 
这种解决办法就是提议者只有一个，也就是paxos里面说的总统。

三、 zookeeper

1. 什么是zookeeper

zookeeper是为了解决分布式一致性问题的工程应用。

zookeeper并没有直接用paxos协议，而是在paxos协议的基础上，提出了符合自己符合实际应用场景的高可用的一致性协议ZAB原子广播协议。

zookeeper分布式一致性的特点：

• 顺序一致性：客户端访问zookeeper的一个节点，发起事务，是排着队到leader那让他发起提议，一个一个来；

• 单一视图：任何节点上的数据都是一样的，所以客户端访问任意节点都看到是相同的数据。

• 可靠性：给了一个客户端反馈，同意他的请求，那么就是真的同意了。

• 实时性：zookeeper保证在一定时间内，比如5秒之后你可以访问到最新数据。这是最终一致性导致的。

2. zookeeper设计目标

• 简单的数据模型：就是文件夹的树形结构

• 可以构建集群：

• 顺序访问：客户端提出了一个事务请求，会获得一个唯一的id编号，用于操作的先后顺序；

• 高性能：这里指的是读取数据

3. zookeeper的几个角色

zookeeper有几个角色：leader、follower、observer；其中observer一般不配置，它也不参与投票，observer可以在不影响写性能的情况下提升集群的读性能； 
zookeeper中节点有实体机器节点，还有znode数据节点。znode数据节点指的是目录文件夹。数据节点有永久数据节点和临时节点。

4. watcher监听机制

zookeeper有watcher监听机制，例如一个临时数据节点，如果客户session中断了，临时节点就删除了，这时watcher就监听到了。这点就是hadoop的HA实现机制，zkfc实现了zookeeper的watcher机制来自动切换。

5. zookeeper的权限

zookeeper的数据节点就是一个文件夹目录，它有自己的权限机制ACL。 
实际zookeeper删除、设置。创建目录，这些就是执行权限。

四、 zab协议

1. zab 的三种状态：

1. Looking/election:系统刚启动时或者Leader崩溃后正处于选举状态；

2. Following：Follwoer节点所处的状态，Follower与Leader处于数据同步阶段；

3. Leading：Leader所处状态，当前集群中有一个Leader为主进程。

2. zab宏观上的三个阶段：

1. 崩溃恢复

2. 快速选举

3. 原子广播

3. zab的微观的四个阶段：

1. 选举

2. 发现

3. 同步

4. 广播 
   客户端提交一个请求到leader然后leader发起提议floower来投票，这个过程都是原子广播

4. zab的节点状态讲解

1. ZooKeeper启动时所有节点初始状态为Looking，这时集群会初始选举出一个Leader节点，选举出的Leader节点切换为Leading状态；

2. 当节点发现集群中已经选举出Leader则该节点会切换到Following 状态，然后和Leader节点保持同步；

3. 当Following节点与Leader失去联系时Follower节点则会切换到Looking状态，开始新一轮选举；

4. 在ZooKeeper的整个生命周期中每个节点都会在Looking、Following、Leading状态间不断转换。

当启动后leader崩溃选举

选举出Leader节点后zab进入原子广播阶段，这是Leader为和自己同步的每个节点Follower只能和一个Leader保持同步Leader节点与Follow节点使用心跳检测来感知对方的存在；

当Leader节点在超时时间内收到来自Follower的心跳检测，那Follower节点会一直与该节点保持连接；若超时时间内Leader没有接收到来自过半Follower节点的心跳检测或TCP连接断开，那Leader会结束当前的领导，切换到Looking状态，所有Follower节点也会放弃该Leader节点切换到Looking状态，所有Follower节点也会放弃该Leader节点切换到Looking状态，然后开始新一轮选举；

5. 详解zab四个阶段：

1. 第一阶段：准备leader选举 
   成为leader的条件： 
   选epoch最大的； 
   epoch相等，选zxid最大的 
   epoch的zxid都相等，选择server id最大的（就是配置zoo.cfg中的myid）。

节点在选举开始读默认投票给自己，当接收其他节点的选票是，会根据上面的条件更改自己的选票并重新发送选票给其他节点，但一个节点的得到票超过半数，该节点会设置自己的状态leading，其他节点会设置自己的状态为following。

什么是epoch，什么是zxid？ 
首先ZooKeeper一个事务包含两部分，一个数数据，一个是id；id是全局唯一的id，数据就是具体操作数据，并且是lastid加1； 
ZooKeeper每个请求都是顺序执行的，强顺序性的； 
epoch是leader标识，zxid是事务标识。

epoch是指：年代，一个领导挂了，另一个领导上任，现在就是新领导的时代了，当产生新领导，事务编号就从0开始。

zxid是总称：前32位是leader编号（epoch），后32位是这个leader下事务编号。

1. 第二阶段：发现阶段 
   发现阶段主要是发现最大的epoch和最大的事务编号； 
   之前说了快速产生准备leader，然后其他节点就是fllower，然后发现阶段就是fllower向leader报告，自己的epoch和事务编号，然后leader排序，选择最大的epoch和最大的事务编号。然后通知fllower去更改它的epoch。

2. 第三阶段：同步阶段 
   leader利用上一个阶段知道最大事务编号，然后通知其他fllower去leader这同步数据。事务编号有可能不一样，所以要同步。保持数据最终一致性。

3. 第四阶段：原子广播阶段 
   这时候leader真正对外提供服务，接受客户端的请求，生成一个数据，半数以上同意，然后就提交事务。剩下的其他节点直接去leader那同步数据。

原来挂掉的leader的事务？

它启动起来，发现他的时代已经过时了，就删除了事务，发现有心的leader，自己就变成fllower，然后就去同步数据。

在选举上，会选举拥有最新提议历史(lastZxid最大)的节点作为leader，这样子就省去了发现最新提议的步骤。这是局域拥有最新提议的节点也有最新提交记录的前提。

6. zab和paxos区别

paxos没有给出leader选举协议，只给出一致性协议。

五、 ZooKeeper在大数据中的应用场景

ZooKeeper 目录有几个特点，有临时目录，永久目录，顺序目录，强一致性(顺序访问)和watcher机制。

利用这些特点，我们可以实现：

• 发布订阅，例如一些配置信息；

• 负载均衡，例如kafka生产，消费均衡；

• master选举，例如hbase利用它hmaster选举；

• 主备切换，例如hdfs的HA利用它进行切换。

1. 发布订阅

例如：我们的数据库配置信息文件就可以放到ZooKeeper上。 
利用ZooKeeper的watcher机制实现配置变更，程序在运行中就可以获取到最新的配置信息，不需要起停。

2. ZooKeeper HA应用（主备切换）

hdfs的HA，它的主备切换用的是ZooKeeper来做Active standby之间切换的。

大致步骤： 
1). 多个nodemanager同时向ZooKeeper注册一个数据节点lock。因为ZooKeeper是强一致性的，所以只能有一个注册成功，注册成功的那个就是active 
2). 没有注册成功的否成了standby，然后在lock目录上注册监听事件watcher。 
注意：注册的lock节点目录是临时节点，如果active挂了，这个目录也就没了，并且这个lock目录是有权限控制的ACL，防止active假死后重新连接出现脑裂。 
3). 主备切换：当active挂掉以后，会话结束，临时目录自动删除。其他standby监听到临时目录删除了，各个standby重新同时进行创建带权限的临时目录。成功的改为active，没有成功的还是standby。 
4). 如果挂掉的active启动后，发现没有权限范围lock临时目录，自动更改成standby状态。

这是ZooKeeper主备切换应用，利用临时目录，ACL，watcher机制实现。

3. master选举

利用ZooKeeper master选举其实很简单，和主备切换一样。 
利用强一致性同时创建同一个目录，最后只能一个成功。 
成功那个节点会返回成功状态，其他节点返回异常，成功的那个就成为master，其他节点就改成slave。

4. zookeeper在hbase中应用

hmaster监控regionserver是否挂掉。

首先，rs（regionserver简称）在ZooKeeper注册一个临时目录rs/[hostname]目录，然后hmaster注册watcher监控rs目录下面变化就可以发现rs服务器是否挂掉。

元数据存储（订阅发布）：每个region存储信息位置和状态，都放在ZooKeeper上存储，以便大家都能订阅目前region所处的状态，比如region是在合并还是在切割，有多少个region分别在哪个regionserver上。所以客户端访问先访问ZooKeeper得到位置信息去读取数据，不经过hmaster。

5. ZooKeeper在kafka中应用

kafka在ZooKeeper注册的信息

首先，kafka会把broker创建到ZooKeeper临时目录上。

/broker/ids/[1-n]表示broker还活着。然后topic信息创建到ZooKeeper临时目录。/brokers/topics/[topicname]/paritiong信息。如果有消费者，消费者也会在ZooKeeper创建自己消费信息的offset信息。等临时目录。

kafka注册broker和topic信息使为了生产消费时负载均衡，这就利用到ZooKeeper负载均衡。消费生产者监控到broker和topic，topic和partition之间的数量，进行重新排序。

上述内容就是ZooKeeper知识点都有哪些，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注行业资讯频道。