Zookeeper

ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Hadoop 和 Hbase 的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

一、Zookeeper基础

1.1 使用场景

• 分布式协调组件：通过 watch 机制可以协调好节点之间的数据一致性
• 分布式锁：通过分布式锁可以做到强一致性
• 无状态化实现
• 负载均衡
• 数据发布/订阅
• 命名服务

1.2 部署

docker-compose.yaml

version: '3.8'
services:
  zookeeper:
    container_name: zk01
    image: zookeeper:3.7.0
    restart: always
    hostname: zk01
    ports:
      - 2181:2181
    environment:
      ZOO_MY_ID: 1
      ZOO_SERVERS: server.1=zk01:2888:3888;2181

zoo.cfg

dataDir=/data
dataLogDir=/datalog
# 基本时间配置（毫秒）
tickTime=2000
# 初始化连接到leader的最大时长，单位为倍数，即初始化时间为tickTime * initLimit
initLimit=5
# follower与leader数据同步的最大时长
syncLimit=2
# 保存数据的快照数量
autopurge.snapRetainCount=3
# 自动触发清除任务时间间隔，以小时为单位，默认为0，表不清除
autopurge.purgeInterval=0
# 客户端与zk的最大并发连接数
maxClientCnxns=60
# 开启standaloneEnabled模式，即独立部署
standaloneEnabled=true
# 开启adminServer
admin.enableServer=true
# 2181是为客户端提供的端口
server.1=zk01:2888:3888;2181

1.3 基本命令

1. 启动|关闭|查看状态

zkServer.sh start|stop|status

2. 进入 zk

zkCli.sh

3. 查看内部数据结构

ls [path]

二、内部数据结构

2.1 是如何存储数据的

Zookeeper 中的数据是保存在节点上的，即 znode，多个 znode 就构成一个树的结构。

如图，a 和 b 就是 Zookeeper 的 znode，创建 znode 方式如下

create /[znode_name]
# 创建节点并创建一个数据
create /[znode_name] [data_name]
# 获取数据
get [znode_name]

2.2 znode结构

Zookeeper 中的 zonode，包含以下几个部分：

• data：保存数据
• acl：权限
  • c：创建权限
  • w：写权限
  • r：读权限
  • d：删除权限
  • a：admin 管理者权限
• stat：描述当前 znode 的元数据
• child：当前节点的子节点

# 查看znode详细信息
get -s /[znode_name]
cZxid:创建节点的事务ID
ctime:创建节点时间
mZxid:修改节点的事务ID
mtime:修改节点时间
pZxid:添加和删除子节点的事务ID
cversion:当前节点的子节点版本号，初始值为-1，每对该节点的子节点进行操作，这个cversion都会自动增加
dataVersion:数据版本初识版本为0，每对该节点的数据进行操作，这个dataVersion都会自动增加
aclVersion:权限版本
ephemeralOwne:如果当前节点是临时节点，该值是当前节点的session id，如果不是临时节点则为0
dataLength:数据长度
numChildren:该节点的子节点个数

2.3 znode类型

• 持久节点：在会话结束后仍会存在
• 持久序号节点：根据先后顺序，会在结点之后带上一个数值，适用于分布式锁的场景（单调递增）
• 临时节点：会话结束后会自动删除，适用于注册与服务发现的场景
• 临时序号节点：跟持久序号节点相同，适用于分布式锁的场景
• 容器节点：当容器节点中没有任何子节点时，该容器节点会被定期删除（60s）
• TTL 节点：可以指定节点的到期时间

持久序号节点创建

create -s /[znode_name]

临时节点创建

create -e /[znode_name]

临时序号节点创建

create -e -s /[znode_name]

容器节点创建

create -c /[znode_name]

TTL 节点创建

# 通过系统配置开启
zookeeper.extendedTypesEnabled=true

持久节点

持久节点在创建后服务端会发送一个 session id，并一直保留着。

临时节点

临时节点在创建时后服务器也会发送一个 session id，在会话持续的过程中客户端会不断向服务端续约 session id 的时间，当客户端没有继续续约，而服务端内部的计时器到期时，就会将该 session id 所对应的 znode 全部删除。

2.4 持久化机制

Zookeeper 的数据是运行在内存中的，所以提供了两种持久化机制：

• 事务日志：Zookeeper 将执行过的命令以日志的形式存储在 dataLogDir / dataDir 中，类似于 redis 的 AOF
• 数据快照：在一定时间间隔内做一次数据快照，存储在快照文件中（snapshot），类似于 redis 的RDB

Zookeeper 通过这两种持久化机制，在恢复数据时先将快照文件中的数据恢复到内存中，再用日志文件中的数据做增量恢复，可以实现高效的持久化。

三、zkCli的使用

1. 递归查询

ls -R /[znode_name]

2. 删除节点

deleteall /[znode_name]

3. 乐观锁删除

delete -v [version] /[znode_name]

4. 给当前会话注册用户，并创建节点赋予该用户权限

addauth digest [user]:[password]
create /[znode_name] auth:[user]:[password]:[privileges]

四、分布式锁

在分布式的环境下，如果在一个节点去上了个锁，当请求被负载均衡分配到了其它节点，那么锁就无法形成互斥，所以节点之间使用 Zookeeper，做一个协调中心，将锁上传到 Zookeeper，其它节点要用到就去 Zookeeper 拿这个锁，这就是分布式锁。

Zookeeper 锁的分类：

• 读锁：大家都可以读，前提是之前没有写锁。（读锁比喻成约会，大家都有机会和女神约会，约会前提是女神没结婚）
• 写锁：只有写锁才能写，前提是不能有任何锁。（写锁比喻成结婚，结婚后只有老公能和女神约会，结婚前提是女神和其他人的关系断干净了）

4.1 上读锁

• 创建一个临时序号节点，节点数据是 read，表示为读锁
• 获取当前 Zookeeper 中序号比自己小的所有节点
• 判断最小节点是否为读锁：
  • 如果是读锁：则上锁失败，因为如果最小节点是读锁，那么后面就不可能有写锁，接着为最小节点设置监听，Zookeeper 的 watch 机制会在最小节点发生变化时通知当前节点，再进行后面的步骤，被称为阻塞等待
  • 如果不是读锁：则上锁成功

4.2 上写锁

• 创建一个临时序号节点，节点数据是 write，表示为写锁
• 获取 Zookeeper 中的所有节点
• 判断自己是否为最小节点：
  • 如果是：上锁成功
  • 如果不是：说明前面还有锁，所以上锁失败，接着监听最小节点，如果最小节点发生变化，则重新进行第二步

羊群效应

假设有一百个请求都是要去写锁，那么就会有一百个请求去监听最小节点，那么 Zookeeper 的压力就会非常大，解决方法是将这一百个请求按请求顺序排列，后一个请求去监听前一个请求即可，实现链式监听。

4.3 watch机制

Zookeeper 的 watch 可以看作是一个触发器，当监控的 znode 发生改变，就会触发 znode 上注册的对应事件，请求 watch 的客户端就会接收到异步通知。

zkCli.sh 中使用 watch

create /test
# 一次性监听，监听节点内容
get -w /test
# 监听目录，但所监听节点下创建和删除子节点不会触发监听
ls -w /test
# 与上面相对，都会触发监听
ls -R -w /test

五、集群部署

Zookeeper 的集群角色有三个：

• Leader：处理集群所有事务的请求，集群只有一个 Leader
• Follower：只处理读请求，参与 Leader 选举
• Observer：只处理读请求，提升集群的性能，但不能参与 Leader 选举

docker-compose.yaml

version: '3.8'
services:
  zk01:
    container_name: zk01
    image: zookeeper:3.7.0
    restart: always
    hostname: zk01
    ports:
      - 2181:2181
    environment:
      ZOO_MY_ID: 1
      # 2888:用于集群内zk之间的通信
      # 3888:用于选举投票
      # 2181:客户端使用
      # 要创建observer则在2181端口后加:observer
      ZOO_SERVERS: server.1=zk01:2888:3888;2181 server.2=zk02:2888:3888;2181 server.3=zk03:2888:3888;2181
    
  zk02:
    container_name: zk02
    image: zookeeper:3.7.0
    restart: always
    hostname: zk02
    ports:
      - 2182:2181
    environment:
      ZOO_MY_ID: 2
      ZOO_SERVERS: server.1=zk01:2888:3888;2181 server.2=zk02:2888:3888;2181 server.3=zk03:2888:3888;2181
      
  zk03:
    container_name: zk03
    image: zookeeper:3.7.0
    restart: always
    hostname: zk03
    ports:
      - 2183:2181
    environment:
      ZOO_MY_ID: 3
      ZOO_SERVERS: server.1=zk01:2888:3888;2181 server.2=zk02:2888:3888;2181 server.3=zk03:2888:3888;2181

通过命令查看节点角色

zkServer.sh status
Mode: leader

连接集群

zkCli.sh -server zk01:2181,zk02:2181,zk03:2181

5.1 ZAB协议

ZAB（Zookeeper Atomic Broadcast）即 Zookeeper 原子广播协议，通过这个协议解决了集群数据一致性和崩溃恢复的问题。

ZAB 协议中节点的四种状态

• Looking：选举状态
• Following
• Leading
• Observing

初始化集群时 leader 的选举

• 当集群中两台节点启动时，就会开始 leader 的选举，选票的格式为 (myid,zXid)
• 第一轮投票时，每个节点会生成自己的选票，即自己的 (myid,zXid)，然后将选票给到对方，这时候每个节点就会有两张选票，即自己的和对方节点的
• 接着就会比较两张选票的 zXid，如果都相同就对比 myid，将大的一票投到投票箱中
• 第二轮投票时，每个节点会将上一轮投出去的选票给到其它节点，然后再对比 (myid,zXid)，将大的一票投出去，就能够选出 leader
• 后来新启动的节点会发现已经有 leader了，就不用做选举的过程了
• 可以看出初始化集群时，leader 的选举主要看 myid

崩溃恢复时的 leader 选举

在 leader 确定了之后，leader 会周期性地向 follower 发送心跳包，当 follower 没有收到 leader 发送过来的心跳包，就会进入选举过程，这时候集群不能对外提供服务。

• 当 leader 挂了之后，follower 的状态会变成 looking
• 接着就进行选举投票，过程和初始化集群时一样

5.2 主从同步原理

5.3 NIO和BIO

NIO

用于被客户端连接的 2181 端口，使用的就是 NIO 的连接模式；客户端开启 watch 时，使用的也是 NIO。

BIO

集群在进行选举时，多个节点之间的通信端口，使用的是 BIO 的连接模式。