【Spring Cloud系统】- Zookeer特性与使用场景

【Spring Cloud系统】- Zookeer特性与使用场景

一、概述

Zookeeper是一个分布式服务框架，是Apache Hadoop的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题。如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。

二、Zookeeper是什么

1. ZooKeeper是分布式协调服务的开源架构，可以用来解决分布式集群中应用系统的一致性问题（例如怎样避免同时操作同一数据造成脏读的问题）；也是为分布式程序提供协调服务的Apache项目。
2. ZooKeeper本质上是一个分布式的小文件存储系统，提供基于类似于文件系统目录树方式的数据存储，并且可以对树中的节点进行有效管理，从而用来维护和监控你存储的数据的状态变化，通过监控数据状态的变化，从而可以达到基于数据的集群管理，诸如：统一命名服务、分布式配置管理、负载均衡、分布式锁、分布式协调等功能。

三、Zookeeper有哪些数据结构

ZooKeeper可以理解一个文件系统，ZooKeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。每一个ZNode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识。

3.1 数据结构图

如上图的每个节点称为一个Znode。每个Znode由3部分组成。

• stat: 此为状态信息，描述该Znode的版本，权限等信息。
• data: 与该Znode关联的数据
• children: 该Znode下的子节点

3.2 节点类型

Znode有两种，分别为临时节点和永久节点。

节点的类型在创建时既被确定，并且不能改变。

临时节点：该节点的生命周期依赖于创建它们的会话，一旦会话结束，临时节点将被自动删除，当然可以也可以手动删除。临时节点不允许拥有子节点。

永久节点：该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。

Znode还有一个序列化的特性，如果创建的时候指定的话，该Znode的名字后面会自动追加一个不断增加的序列号。序列号对于此节点的父节点来说是唯一的，这样便于记录每个子节点创建的先后顺序。它的格式为"%10d"(10位数字，没有数值的数位用0补充，例如：“000000001”)。

因为有序列化属性，这样Zookeeper便有四种类型的Znode节点，分别对应：

• PERSISTENT：永久节点
• EPHEMERAL：临时节点
• PERSISTENT_SEQUENTIAL：永久节点、序列化
• EPHEMERAL_SEQUENTIAL：临时节点、序列化

3.3 节点类型

每个znode都包含了一系列的属性，通过命令get，可以获得节点的属性。

• dataVersion：数据版本号，每次对节点进行set操作，dataVersion的值都会增加1（即使设置的是相同的数据），可有效避免了数据更新时出现的先后顺序问题。

• cversion ：子节点的版本号。当znode的子节点有变化时，cversion 的值就会增加1。

• cZxid ：Znode创建的事务id。

• mZxid ：Znode被修改的事务id，即每次对znode的修改都会更新mZxid。

  对于zk来说，每次的变化都会产生一个唯一的事务id，zxid（ZooKeeper Transaction Id）。通过zxid，可以确定更新操作的先后顺序。例如，如果zxid1小于zxid2，说明zxid1操作先于zxid2发生，zxid对于整个zk都是唯一的，即使操作的是不同的znode。

• ctime：节点创建时的时间戳。

• mtime：节点最新一次更新发生时的时间戳

• ephemeralOwner:如果该节点为临时节点, ephemeralOwner值表示与该节点绑定的session id. 如果不是, ephemeralOwner值为0。

四、Zookeeper有哪些核心功能

4.1 保证数据一致性

保证数据的一致性有两种情况:

• 重新选取出leader后的数据同步。
• leader处理完事务请求后与follow保持数据一致。

首先是重新选取出新leader后的数据同步

通过FastLeaderElection选举算法选出leader，选出leader之后，leader需要与其他节点进行同步，当超过一半的follow与leader进行同步完成后，leader才能成为真正的leader,然后follow会带上自己最大的ZXID尝试与leader连接，来确定数据是否同步。

其次是leader处理完成事务请求后与follow保持数据一致

事务请求全部是由leader处理的，当leader收到请求后，会将事务请求转化为事务Proposal，由于leader会为每一个follow创建一个队列，所以leader会将事务放入响应队列中，按顺序处理事务请求，来保证事务的顺序性。之后会在队列中顺序向其他节点广播该提案。follow收到后会将其以事务的形式写入到本地日志中，并向leader发送反馈ack，leader会等待其他follow的回复，当收到一半以上的follow响应时，leader会向其他节点发送commit消息，同时leader提交该提案。当follow将数据同步完成之后，leader会将该follow加入到真正可用的follow列表中。

4.2 更新和监听

ZooKeeper支持watch的概念。客户端可以在znode上设置监视，当znode有事件发生时，通知给感兴趣的客户端。通知变化时收到通知。非常适用于保障分布式情况下的数据一致性。dubbo中使用zk作为注册中心等都用到了zk的更新监听功能。

五、Zookeeper有哪些权限控制

ZooKeeper通过ACL权限控制列表来控制其对znode节点的访问权限。ACL权限与Unix文件系统中的权限控制类似，使用权限位限制指定角色对znode节点的各节点操作，下面详细介绍ZooKeeper中ACL权限控制。

5.1 权限列表

zookeeper中对znode节点的操作权限主要有以下五种，我们可以通过其简写的任意组合来实现对znode节点的不同权限控制。

5.2 ACL权限特点

Zookeeper权限控制有以下几个特点：

1. zookeeper的权限是基于znode节点的，需要对每个节点设置权限。
2. znode节点支持同时设置多种权限方案和多个权限。当znode有多种权限的时候，只要有一个权限允许当前操作，即可执行当前操作，即多个权限之间为或的关系。
3. 子节点不会继承父节点的权限，客户端没有权限访问当前节点，但是可以访问当前节点的子节点。
4. 使用setAcl命令对节点进行权限设置会覆盖掉原来的权限。

六、Zookeeper数据持久化

ZooKeeper数据的组织形式为一个类似文件系统的数据结构，而这些数据都是存储在内存中的，所以我们可以认为，ZooKeeper是一个基于内存的小型数据库。

如果数据只存储在内存中的话，那么在ZooKeeper宕机或者断电的情况下，数据将会丢失，所以ZooKeeper也制定了一些数据持久方式：

• 事务日志log
• 数据快照snapshot

6.1 事务日志log文件

针对每一次客户端的事务操作（写）,ZooKeeper都会将他们记录到事务日志中，当然，ZooKeeper也会将数据变更应用到内存数据库中，我们可以在ZooKeeper的主配置文件zoo.cfg中配置内存中的数据持久化目录，也就是事务日志存储路径dataLogDir。如果没有配置dataLogDir（非必填），事务日志将存储到dataDir（必须填）。

6.2 事务日志log文件

数据快照是ZooKeeper数据存储中另–个非常核心的运行机制。顾名思义，数据快照用来记录ZooKeeper服务器上某一个时刻的全量内存数据内容，并将其写入到指定的磁盘文件中。

文件存储：

快照文件存储在dataDir属性配置的目录下。

和事务日志文件的命名规则一致，快照数据文件也是使用ZXID的十六进制表示来作为文件名后缀，该后缀标识了本次数据快照开始时刻的服务器最新ZXID。这个十六进制的文件后缀非常重要，在数据恢复阶段，ZooKeeper会根据该ZXID来确定数据恢复的起始点。

和事务日志文件不同的是ZooKeeper的快照数据文件没有采用“预分配”机制，因此不会像事务日志文件那样内容中可能包含大量的“0”。每个快照数据文件中的所有内容都是有效的，因此该文件的大小在一定程度上能够反映当前ZooKeeper内存中全量数据的大小。

七、总结

Zookeeper作为一个分布式协调服务，由于其通用性，所以在众多软件开发中被使用。它一般包括存储数据和监听功能，主要提供节点选举、统一配置文件管理、发布和订阅消息、集群管理等功能。在以后的博文中讲详细讲解每个部分详细使用。