ZooKeeper知识点都有哪些

本篇文章为大家展示了ZooKeeper知识点都有哪些，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。

站在用户的角度思考问题，与客户深入沟通，找到湘阴网站设计与湘阴网站推广的解决方案，凭借多年的经验，让设计与互联网技术结合，创造个性化、用户体验好的作品，建站类型包括：网站制作、成都网站设计、企业官网、英文网站、手机端网站、网站推广、域名注册、网页空间、企业邮箱。业务覆盖湘阴地区。

一、 从集中式到分布式

1. 集中式

集中式特点：不用考虑网络分区，宕机问题，协作问题。但是昂贵。

2. 分布式

分布式：由多台机器通过网络通信组成，多节点机器，分布式，故障发生频率大。 
故障原因：网络问题，多台机器网络通信容易超时，中间有可能断掉造成分区。 
网络分区：俗称脑裂。 
网络的三态问题：要么连接成功，要么失败，要么超时。

所以分布式主要是网络方面和机器方面的问题，最大问题是网络问题。

3. ACID

例如数据库的事务

原子性：要么成功，要么失败； 
一致性：如果出现异常数据，还是原来的那份 
隔离性：各个会话之间是相互独立的 
持久性：就是提交后的数据永久保存在磁盘上，不丢失。

4. CAP

一致性：多台机器拥有相同副本 
可用性：在适合的时间响应客户端 
分区容错性：不能出现网络分区

5. BASE

分布式主要的问题是网络，所以我们优先处理分布式的网络，然后在一致性和可用性之间权衡。这时提出了BASE就是对CAP的一致性和可用性的权衡结果。 
BASE 基本可用，最终一致性

最终一致性：就是你提交一台机器，其他机器最终会把你提交的那台机器给同步到自己上。

二、 一致性

主的控制机器就叫协调者，副本机器叫参与者

1. 2PC

两个阶段，提交事务和执行事务。 
提交事务 
1). 询问 
2).执行初始化（执行提交）

执行事务

2PC的故障情况 
单台机器 
1. 协调者故障，那么有个备用协调者接管，并且查询参与者当前执行到什么地步，然后接着执行下去。 
2. 参与者故障，那么协调者会等待它重启，然后再执行下去。

这两种情况，都只会阻塞，并不会不一致性。

同时故障： 
协调者和参与者同时故障 
例如：有机器1，2，3，4。其中4是协调者，1，2，3是参与者 
4给1，2发完提交事务后故障了，正好3这个时候也故障了，注意这是3是没有提交事务数据的。现在备用协调者启动了，去询问参与者，用于3死掉了，一直不知道它处于什么状态（接受了提交事务，还是反馈了能执行还是不能执行3个状态）。 
面对这种情况，让1，2回归停止事务，3恢复以后，不管是什么状态，直接停止事务，回滚，这样子就保证了一致性。 
这是2PC的漏洞，当同时故障了，就全部回滚，效率低下，代价大

缺点

当协调者出错，同时参与者也出错时，两阶段无法保证事务执行的完整性。
考虑协调者再发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交。

2. 3PC

2PC 当时只考虑如果单机故障的情况，并没有考虑协调者和参与者同时故障的情况。3PC就是对2PC漏洞的补充协议。它把2PC中的提交事务请求一分为二，添加了一个状态（准备阶段）。做到就算两个同时故障也不阻塞，并且保证一致性。

事务询问阶段（can阶段）

事务准备阶段 （pre）（包括执行提交）

执行事务阶段 （do commit）（将状态更改）

下面例子分析： 
1. 4是协调者 ，1，2，3 是 参与者，当新闻的节点，协调者4和参与者3同时挂掉了。这时候备用的协调者启动了，询问了1和2的状态，都在can阶段，回滚代价下，直接回滚。当3重新启动了发现自己是can阶段，回滚代价下，执行回滚，停止事务。这样子就摆在了3个节点数据一致性。3PC对应2PC就是减少回滚代价。

1. 当3个参与者都进入到per准备阶段，说明它们都接受到提交询问，并且都表决过（意思是都领到了数据），这时协调者4和参与者3突然死掉了。备用协调起来后，询问其他参与者状态，一看都到pre阶段了，说明都领到了数据包括死掉的3，因为他表决过才进入到准备阶段，所以他让大家都提交了。当3重启后，看了日志，发现自己已经到准备阶段时死掉了，可以执行提交，这样保证了数据一致性。

3. paxos

有个叫paxos小岛，他们每项 决定都得通过提议然后半数才能生效，每个决定的提议都有一个唯一的全局编号，这个编号只能自增长，不能后退。 
何为通过：就是提议的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知识点都有哪些，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注创新互联行业资讯频道。