Zookeeper是怎样保证自身的高可用的？及 zookeeper基本概念

た入场券 2022-12-29 06:51 237阅读 0赞

### Zookeeper是怎样保证自身的高可用的？ ###

*  一
 *   *  Zookeeper的ZAB协议和Paxos协议
     *  Zookeeper集群中的机器数量设置
 *  Zookeeper的基本概念
 *   *  集群角色
     *  系统模型
     *  会话（Session）
     *  数据节点（Znode）
     *  版本
     *   *  Watcher
         *  ACL
         *  Zookeeper的设计目的
         *  Zookeeper的数据模型

# 一 #

首先可以想到的是，假如zookeeper只有一个的话，其也无法保证其自身的高可用，所以zookeeper本身也是以集群的形式存在的。对比学校大门的安保问题，我们很容易能都想到的一种方法是可以有多个zookeeper，在某一时刻由一个主要的zookeeper对外提供服务，当其出现问题时，从剩下的多个zookeeper中快速选出来一个继续对外提供服务就可以了。Zookeeper本身就是基于这种思想来设计的

Zookeeper采用了一个称之为ZAB的协议来保证自身的高可用。其来源于Paxos选举协议，其也是一个用来保证分布式一致的一个经典协议。在历史上，Paxos协议是从二阶段提交协议演变到三阶段提交协议之后再演变成的。

在分布式系统中，每一个机器节点虽然都能够明确的知道自己在进行事务操作过程中的结果是成功或失败，但是无法直接获取到其他分布式节点的操作结果（需要通过网络进行结果传输）。因此，当一个事务操作需要跨越多个分布式节点的时候，为了保持事务处理的ACID\#\# 二级目录  
（原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability））  
特性，就需要引入一个称之为“协调者（Coordinator）”的组件来统一调度所有分布式节点的执行逻辑，这些被调度的分布式节点则被称为“参与者”（Participant）。协调者负责调度参与者的行为，并最终决定这些参与者是否要把事务真正提交。基于这个思想，衍生出了二阶段提交和三阶段提交两种协议两种一致性算法。  
生活中大部分工作的形式都是分布式的，比如我们将来最常见的工作情景：项目经理将一个大项目分成了前后台（或者更多的部分），指派给不同的员工，每个人只负责自己的事情，所有干活的员工就是参与者的角色，项目经理就是协调者的角色。

## Zookeeper的ZAB协议和Paxos协议 ##

二阶段提交和三阶段提交协议和Paxos协议都是分布式应用程序的通用协议，即在大部分的分布式应用程序中都可以使用。ZAB（zookeeper Atomic Broadcast）zookeeper原子消息广播协议）协议是zookeeper设计之初专门为雅虎内部那些高吞吐量、低延迟、健壮、简单的分布式场景设计的。所以ZAB不是一种通用型算法，而是一种特别为zookeeper设计的崩溃可恢复的原子消息广播算法。ZAB算法可是看成是paxos协议的一种具体实现，理解Paxos协议较为困难，我们不做掌握。  
Zookeeper中将自己的角色系统设置主要为Leader、Flower、OBServer。Leader和Flower都是zk的server，只不过由Leader（只会存在一个，类似于Hadoop的NameNode）对外提供服务，众多Flower（类似于secondary namenode，不过Flow会有多个）随时准备等Leader出现问题时选举出一个新leader来继续对外提供以保证zk服务的高可用。\\

## Zookeeper集群中的机器数量设置 ##

Zookeeper为了防止出现二阶段和三阶段提交协议中出现的数据不一致的情况（例如：网络出现问题，可能会将zk集群分成多个小集群），规定了只有zk集群中半数以上的server存活时才能对外提供服务。所以我们一般安装zk集群时，一般设置为奇数台zk的server。  
假如，我们的zk集群有6个server，那么我们最多允许有两个server挂掉zk集群还能继续对外提供服务。但是如果我们的zk集群有5个server的话，我们同样最多允许有两个server挂掉也能继续提供服务。所以一般zk集群安装时server的数量是奇数个。

# Zookeeper的基本概念 #

## 集群角色 ##

通常在分布式系统中，构成一个集群的每一台机器都有自己的角色，最典型的集群模式是Master/Slave模式（主从模式）。在这种模式中，我们把能够处理所有写操作的机器称为Master，把所有通过异步复制方式获取最新数据，并提供读服务的机器称为Slave机器。  
Hadoop就是一个典型的案例。  
而在zookeeper中，这些概念被颠覆了。它没有沿用传统的Master/Slave概念，而是引入了Leader、Flower和Observer（3.3版本开始启用）三种角色。Zookeeper集群中的所有机器通过一个Leader选举过程来选定一台称为“Leader”的机器，Leader服务器为客户端系统读和写服务。除Leader外，其他机器包括Flower和Observer。Flower和Observer都能够提供读服务，唯一的区别在于，Observer机器不参与Leader选举过程，也不参与写操作的“过半写成功”策略，因此Obsercer可以在不影响写性能的情况下提升集群的读性能。  
总结如下图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d6cTE4ODQ1MjgwNjEw_size_16_color_FFFFFF_t_70]

## 系统模型 ##

如下图所示：![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d6cTE4ODQ1MjgwNjEw_size_16_color_FFFFFF_t_70 1]

## 会话（Session） ##

Session是指客户端会话。在zookeeper中，一个客户端连接是指客户端和服务器之间的一个TCP长连接。  
Zookeeper对外的服务端口默认是2181，客户端启动的时候，首先会与服务器建立一个TCP连接，从第一次连接建立开始，客户端会话的生命周期就开始了，通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能够向zookeeper服务器发送请求并接受响应，同时还能够通过该连接接收来自服务器的watch事件通知，Session的sessionTimeOut值用来设置一个客户端会话的超时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致的客户端连接断开时，只要在sessionTimeOut规定的时间内能够重新链接上集群中任意一台服务器，那么之前创建的会话仍然有效。

## 数据节点（Znode） ##

在分布式中我们通常说的“节点”是指组成集群的每一台机器。然而，在zookeeper中，“节点”分为两类，第一类同样是指构成集群的机器，我们称之为机器节点。第二类则是指数据模型中的数据单元，我们称之为数据节点——Znode。Zookeeper将所有数据存储在内存中，数据模型是一棵树（ZNode Tree），由斜杠（/）进行分割的路径，就是一个Znode，例如/foo/path1。每个ZNode上都会保存自己的数据内容，同时还会保存一系属性信息。  
在zookeeper中，ZNode可以分为持久节点和临时节点两类。所谓持久节点是指一旦这个ZNode被创建了，除非主动进行ZNode的移除操作，否则ZNode将一直保存在zookeeper上。而临时节点就不一样了，他的生命周期和客户会话绑定，一旦客户端会话失效，那么这个客户端创建的所有临时节点都会被删除。另外，zookeeper还允许用户为每一个节点添加一个特殊的属性SEQUENTIAL。一旦节点被标记上这个属性，那么在这个节点被创建的时候，zookeeper会自动在其节点名后面追加上一个整形数字，这个整形数字是由父节点维护的自增数字。  
Zookeeper在各种分布式场景下发挥作用的主要方式就是数据节点和监控器，我们可以给数据节点赋予任意我们想赋予的含义，来协助我们更好的处理分布式程序中所面临的问题，具体案例详见后文中的zookeeper 的其他典型应用场景。  
zookeeper的目录结果： 也是也treenode树形结构

目录也是文件。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d6cTE4ODQ1MjgwNjEw_size_16_color_FFFFFF_t_70 2]

## 版本 ##

Zookeeper的每个znode上都会存储数据，对应于每个znode，zookeeper都会为其维护一个叫作stat的数据结构，stat中记录了这个znode的三个数据版本，分别是version（当前znode的版本）、cversion（当前znode子节点的版本）和aversion（当前znode的acl版本）。  
Acl: access control list（防火墙）

### Watcher ###

Watcher（事件监听器），是zookeeper中的一个很重要的特性。Zookeeper允许用户在指定节点上注册一些watcher，并且在一些特定的事件触发的时候，zookeeper服务端会将事件通知到感兴趣的客户端上去。

### ACL ###

zookeeper采用ACL（Access Control Lists）策略来进行权限控制，类似于UNIX文件系统的权限控制。zookeeper定义了如下5种权限。  
CREATE：创建子节点的权限。  
READ：获取子节点数据和子节点列表的权限。  
WRITE：更新节点数据的权限。  
DELETE：删除子节点的权限。  
ADMIN：设置节点ACL的权限。

### Zookeeper的设计目的 ###

1.最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。  
2 .可靠性：具有简单、健壮、良好的性能，如果消息m被一台服务器接受，那么它将被所有的服务器接受。  
3 .实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。  
4 .等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。  
5.原子性：更新只能成功或者失败，没有中间状态。  
6 .顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。

### Zookeeper的数据模型 ###

Zookeeper的结构类似标准的文件系统，但这个文件系统中没有文件和目录，而是统一使用节点(node)的概念，称为znode。Znode作为保存数据的容器(限制在1mb以内)，也构成了一个层次化的命名空间。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d6cTE4ODQ1MjgwNjEw_size_16_color_FFFFFF_t_70 3]  
Zookeeper目录中的每一个节点对应着一个znode，每个znode维护着一个属性结构，它包含数据的版本号、时间戳、等信息。Zookeeper就是通过这些属性来实现它特定的功能。每当znode的数据改变时，相应的版本号会增加，每当客户端查询、更新和删除数据时，也必须提供要被操作的znode版本号，如果所提供的数据版本号与实际的不匹配，那么将会操作失败。

节点属性：![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d6cTE4ODQ1MjgwNjEw_size_16_color_FFFFFF_t_70 4]  
Znode是客户端访问的Zookeeper的主要实体，它包含了以下主要特征：  
(1) Watch  
Znode状态发生改变时(增删改等操作)，watch (监视器)机制可以让客户端得到通知，并且仅仅只会触发一次watch。  
在读操作exists、getChildren和getData上可以设置监视器，这些监视器可以被写操作create、delete和setData触发。ACL相关的操作不参与任何监视器。当一监视器触发时，会产生一个事件，这个监视器和触发它的操作共同绝地沟了监视器事件类型。  
当所监视的znode被创建子节点、删除或其他数据更新时，设置在exists操作上的监视器将会被触发。  
当所监视的znode被删除或其更新时，设置在getData上的监视器将会被触发，创建znode不会触发getData上的监视器，因为getData操作成功执行的前提是znode必须已经在。  
当所监视的znode的一个子节点被创建或删除时，或监视的znode自己被删时，设置在getChildren操作上的监视器将会被触发。  
设置监视器的操作及对应的触发器![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d6cTE4ODQ1MjgwNjEw_size_16_color_FFFFFF_t_70 5]  
(2) 数据访问控制  
每个znode创建时间都会有一个ACL列表，用于决定谁可以执行那些操作。  
(3) 临时节点  
Zookeeper节点有两种：临时节点和持久节点。节点类型在创建时确定，并且不能修改。临时节点生命周期依赖创建它的会话，一旦会话结束，临时节点将会被删除。临时节点不允许有子节点。  
(4) 顺序节点  
当创建znode 时设置了顺序节点，那么该znode路径之后便会附加一个递增的计数，这个计数对于此节点的父节点来说是唯一的。  
例如：一个客户端请求创建一个名为/a/b-的顺序节点，则所创建znode的名字可能是a/b-5，稍后另外一个名为/a/b-的顺序节点被创建，计数器会给出一个更大的值来保证znode名称的唯一性，例如/a/b-6。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d6cTE4ODQ1MjgwNjEw_size_16_color_FFFFFF_t_70]: /images/20221120/b5acf2ebfd2d4cc2a71a84192ab6180d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d6cTE4ODQ1MjgwNjEw_size_16_color_FFFFFF_t_70 1]: /images/20221120/1cba721de6714040bf4927127d2bebd0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d6cTE4ODQ1MjgwNjEw_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20201221102420729.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d6cTE4ODQ1MjgwNjEw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d6cTE4ODQ1MjgwNjEw_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20201221102545304.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d6cTE4ODQ1MjgwNjEw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d6cTE4ODQ1MjgwNjEw_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20201221102603921.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d6cTE4ODQ1MjgwNjEw,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d6cTE4ODQ1MjgwNjEw_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20201221102626892.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d6cTE4ODQ1MjgwNjEw,size_16,color_FFFFFF,t_70