ZooKeeper初学习笔记

65 阅读 0 评论 43 点赞

我是靠谱客的博主天真发卡，最近开发中收集的这篇文章主要介绍ZooKeeper初学习笔记，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

zookeeper是⼀个伪分布式应⽤程序提供的⼀个分布式开源协调服务框架。是Google的Chubby的⼀个开源实现，是Hadoop和Hbase的重要组件。主要⽤于解决分布式集群中应用系统的⼀致性问题。
提供了基于类似Unix系统的目录节点树方式的数据存储。
可用于维护和监控存储数据的状态的变化，通过监控这些数据状态的变化，从而达到基于数据的集群管理

提供的功能包括：配置维护、域名服务、分布式同步、组服务等

Zookeeper 的核心是原子广播机制，这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 Zab 协议。Zab 协议有两种模式，它们分别是恢复模式和广播模式

Zookeeper 作为分布式系统协调者和管理者，承担着联结分布式系统的各组件来组成一个完整服务的职责

功能

1. 管理系统中独特的/统一的信息：
一个分布式系统的各节点可能需要一个规范的、各节点的唯一的命名（例如节点名、CPU编号等），ZK可以实现这个的应用场景。

各个节点也会有一致的信息，例如每个节点的主配置信息。为了管理方便，新加入的节点也需要快速同步这些信息。使用ZK可以方便的做到。

2. 集群状态监控和通知：

分布式系统中的每个节点需要知道整个系统的状态、知道系统中每个节点的状态：当有新节点加入时它需要知道、当有节点出现故障时它需要知道、当有节点退出时它需要知道。ZK就是这样一个“通知工具”。

ZooKeeper数据一致性
ZooKeeper是高性能、可扩展的，为应用提供了以下的数据一致性(每个server保存⼀份相同的数据副本，client⽆论连接到哪个server,数据都是⼀致的)保障：
1）顺序一致性: 来自客户端的更新将严格按照客户端发送的顺序处理；
2）原子性: 更新或者成功或者失败，不存在部分成功或者部分失败的场景；
3）单一视图: 无论客户端连接到哪个服务器，看到的都是一样的视图；
4）可靠性: 一旦一个更新生效，它将一直保留，直到再次更新；
5）实时性: 在⼀定时间范围内，client能读到最新数据

ZooKeeper有哪些需要配置的属性？

tickTime: ZooKeeper运行的基本时间单元

dataDir: 存储持久数据的本地文件系统位置

clientPort: 监听客户端连接的端口(常用的端口是2181)

数据管理功能：
创建节点： create /aaa ‘ppppp’

查看节点下的子节点： ls /aaa

获取节点的value： get /aaa

修改节点的value： set /aaa ‘mmmmm’

删除节点：rmr /aaa

数据监听功能：
ls /aaa watch

ZooKeeper有哪些状态？
ZooKeeper对象在一个生命周期内，有好几个状态。

getStates()方法能查询出ZooKeeper的状态。

Connecting : 新建ZooKeeper实例时

Connected ：建立连接后

SyncConnected：使用“观察”机制，状态转换时

Disconnected：断开后，状态。一般连接丢失后，它会自动尝试重新连接。

Closed : ZooKeeper被认为不是活跃的，不可用了。

ZooKeeper数据模型中的每个znode都维护着一个 stat 结构。一个stat仅提供一个znode的元数据。它由版本号，操作控制列表(ACL)，时间戳和数据长度组成。

版本号 - 每个znode都有版本号，这意味着每当与znode相关联的数据发生变化时，其对应的版本号也会增加。当多个zookeeper客户端尝试在同一znode上执行操作时，版本号的使用就很重要。
操作控制列表(ACL) - ACL基本上是访问znode的认证机制。它管理所有znode读取和写入操作。
时间戳 - 时间戳表示创建和修改znode所经过的时间。它通常以毫秒为单位。ZooKeeper从“事务ID"(zxid)标识znode的每个更改。Zxid 是唯一的，并且为每个事务保留时间，以便你可以轻松地确定从一个请求到另一个请求所经过的时间。
数据长度 - 存储在znode中的数据总量是数据长度。你最多可以存储1MB的数据。
numChildren - znode子节点数量
ephemeralOwner- 如果是临时节点，这个是znode拥有者的session id。如果不是临时节点则是0

ZK就是使用这些属性来实现特殊功能的。当一个客户端要对某个节点进行修改时，必须提供该数据的版本号，当节点数据发生变化是其版本号就会增加

Znode具有如下特性：

Watches：客户端可以在节点上设置Watches（可以叫做监视器）。当节点状态发生变化时，就会触发监视器对应的操作，当监视器被触发时，ZK服务器会向客户端发送且只发送一个通知——一个watcher相当于一个一次性的触发器，watcher只会简单通知事件，但不会说明具体事件内容，无论服务端还是客户端，一旦一个Watcher被触发，Zookeeper都会将其从相应的存储中移除
数据访问：ZK上存储的数据需要被原子性的操作（要么修改成功要么回到原样），也是就读操作将会读取节点相关所有数据，写操作也会修改节点相关所有数据，，而且每个节点都有自己的ACL。

拥有下述四种类型节点

create -s /NODE_NAME DATA # -e参数为创建临时节点，如果不带参数则创建持久节点

PERSISTENT	持久化节点，一旦创建，除非主动调用删除操作，否则一直存储在zk上
PERSISTENT_SEQUENTIAL	顺持久顺序节点，该节点创建后持久存在，相对于持久节点它会在节点名称后面自动增加一个10位数字的序列号，这个计数对于此节点的父节点是唯一，如果这个序列号大于2^32-1就会溢出。
EPHEMERAL	临时节点，与客户端会话绑定，一旦客户端会话失效，这个客户端所创建的所有临时节点都会被移除；（也可以手动删除，临时节点不能拥有子节点）
EPHEMERAL_SEQUENTIAL	临时顺序节点，具有临时节点特征，但是它会有序列号，分布式锁中会用到该类型节点

Znode的访问控制
ACL全称是Access Control List，访问控制列表，zookeeper中ACL由三部分组成，即Scheme:id:permission

scheme是验证过程中使用的检验策略，有五种类型：world、auth、digest、IP、super
id是权限被赋予的对象，比如ip或某个用户
permission为可以操作的权限，有5个值：crdwa，分别表示create、read、delete、write、admin
通过setAcl path acl命令可以设置节点的访问权限，path是节点路径，acl是要设置的权限(crdwa)。通过getAcl path可以查看节点的权限信息。需要注意的是节点的acl不具有继承关系。

zookeeper集群模型

zookeeper集群是一主多从的模型，节点分成三种角色：leader、follower和observer。leader负责写、follower和observer负责读

集群规则为：2N + 1 台，N > 0，即最少需要 3 台。

因为 ZK 集群的机制是只要超过半数的节点正常，集群就能正常提供服务。

只有在 ZK 节点挂的太多，只剩一半或不到一半节点能工作，集群才失效。

在数据读写方面，由于 zookeeper 集群是一个主从结构集群，故主节点负责处理写请求，然后将写请求同步给从节点，从而实现整个集群的数据一致性。所以 zookeeper 也是适合于读多写少的应用场景的

节点角色	主要功能
Leader	1.负责所有的写请求，也可以处理读请求 2.维持与从节点，即 follower 节点和 observer 节点的心跳，从而实时监测从节点的运作情况和通知从节点自身的运作情况，如假如 leader 节点宕机了，则不会再发心跳包给 follower 节点和 observer 节点，此时 follower 节点才能发现主节点挂了，从而进行新一轮 leader 选举实现崩溃恢复
Follower	处理读请求和投票对于写请求，首先统一转发给 leader 节点，然后在 leader 节点执行写请求时，会将写请求以协议消息的方式发送给所有 follower 节点，通过投票来决定是否需要执行此次写请求，所以 follower 节点需要 ack 响应 leader 节点来进行投票。如果投票通过，则 leader 向所有的 follower 和 observer 节点发送提交 commit 请求，从而在所有节点执行本次数据写操作。（两阶段提交）除了对 leader 节点的写请求进行投票外，follower 节点还需要对 leader 节点的选举进行投票，从而选举出leader节点。
Observer	处理读请求，observer 节点没有投票权，即不参与 leader 节点发起的写请求的投票和 leader 选举的投票，只是从 leader 节点同步数据，处理读请求，所以 observer 节点主要是对 zookeeper 集群的读请求的拓展，所以说 zookeeper 是适合读多写少的应用场景

读消息可以通过leader和所有的follower，写消息必须通过leader

Leader选举(选举算法有FastLeaderElection和AuthLeaderElection)

Leader选举是保证分布式数据一致性的关键所在。Leader选举分为Zookeeper集群初始化启动时选举和Zookeeper集群运行期间Leader重新选举两种情况

Zookeeper节点状态
LOOKING：寻找Leader状态，处于该状态需要进入选举流程
LEADING：领导者状态，处于该状态的节点说明是角色已经是Leader
FOLLOWING：跟随者状态，表示Leader已经选举出来，当前节点角色是follower
OBSERVER：观察者状态，表明当前节点角色是observer

Zookeeper的Leader节点在收到数据变更请求后的读写流程——先写磁盘再写内存

事务ID
ZooKeeper状态的每次变化都接收一个ZXID（ZooKeeper事务id）形式的标记。ZXID是一个64位的数字，由Leader统一分配，全局唯一，不断递增。
ZXID展示了所有的ZooKeeper的变更顺序。每次变更会有一个唯一的zxid，如果zxid1小于zxid2说明zxid1在zxid2之前发生。

Zookeeper配置参数解析

1.tickTime=2000:通信心跳数，表示ZooKeeper服务器与客户端心跳时间，单位为毫秒。
ZooKeeper使用的基本时间，服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个tickTime时间就会发送一个心跳。它用于心跳机制，并且设置最小的session超时时间为心跳时间的两倍(session的最小超时时间是2*tickTime)。

2.initLimit =10:Leader与Follower初始通信时限
集群中的Follower跟随者与Leader领导者服务器之间初始连接时能容忍的最大心跳数（tickTime的数量）。用它来限定集群中的Zookeeper服务器连接到Leader的时限。也就是表示集群初始启动时，Leader与Follower集群启动时，刚开始通信的最大延时时间(10 * tickTime)。

3.syncLimit=5:Leader与Follower通信时限
集群中Leader与Follower之间的最大响应时间单位，假如响应超过syncLimit * tickTime，Leader认为Follwer死掉，从服务器列表中删除Follwer。

4.dataDir:数据文件目录+数据持久化路径
主要用于存储ZooKeeper集群中的数据。

5.clientPort:2181：客户端连接端口