Walter's Website

# zookeeper

# zookeeper基础介绍

# zookeeper的来源

有雅虎开发，后捐献给了Apache组织。 在Hadoop生态系统中，许多项目的Logo都采用了动物，比如 Hadoop 和 Hive 采用了大象的形象，HBase 采用了海豚的形象，而从字面上来看 ZooKeeper 表示动物园管理员，所以大家可以理解为 ZooKeeper就是对这些动物（项目组件）进行一些管理工作的。

对于单机环境多线程的竞态资源协调方法，我们一般通过线程锁来协调对共享数据的访问以保证状态的一致性。 但是分布式环境如何进行协调呢？于是，Google创造了Chubby，而ZooKeeper则是对于Chubby的一个开源实现。 ZooKeeper是一种为分布式应用所设计的高可用、高性能且一致的开源协调服务，它提供了一项基本服务：分布式锁服务。由于ZooKeeper的开源特性，后来我们的开发者在分布式锁的基础上，摸索了出了其他的使用方法：配置维护、组服务、分布式消息队列、分布式通知/协调等。它被设计为易于编程，使用文件系统目录树作为数据模型。

# zookeeper的五大特性

  • 顺序一致性
    • 客户端的更新顺序与他们发送的顺序相一致
  • 原子性
    • 更新操作要么全部成功，要么全部失败
  • 单一视图
    • 无论客户端连接到哪一个服务器，都可以看到相同的zookeeper视图
  • 可靠性
    • 一旦一个更新操作被应用，那么在客户端再次更新它之前，其值将不会改变
  • 实时性
    • 在特定的一段时间内，系统的任何变更都将被客户端检测到

# zookeeper的使用场景

  • 配置管理
    • 分布式系统，很多服务部署在不同的服务器上，都有自己的一套配置，逐台更新配置非常麻烦。使用zk统一管理，各服务监听zk配置节点变化，一旦变化所有服务都会得到zk通知，然后从leader获取新配置，并完成更新。
  • 命名服务（服务注册与发现）
    • 服务提供方将自己的服务名、ip等注册到zk，服务调用方监听zk注册节点，获得最新的服务提供方地址，进行调用。
  • 分布式锁服务
    • 保持独占：单进程（抢注临时节点，谁创建成功，谁获得锁）
    • 控制时序：加锁排队（创建有序临时节点，按顺序获得锁）
  • 集群管理
    • 是否有机器加入或退出
    • 选举leader

# zookeeper系统模型

An image

# zookeeper角色

An image

# zookeeper数据模型

# 数据结构——Znode

  • 数据结构——Znode An image

    • 每个Znode兼具文件和目录两种特点

      • 像文件一样维护着数据、原信息、ACL、时间戳等数据结构
      • 像目录一样可以作为路径标识的一部分

    • 每个Znode有3各部分组成：

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

    • zk规定节点Znode的数据大小不能超过1M，但实际上我们在Znode上的数据量应尽可能的小，因为数据量过大会导致zk性能明显下降

  • Znode节点类型
    • 临时节点-ephemeral：
      • 该节点的生命周期依赖于创建他们的会话。一旦会话（Session）结束，临时节点将被自动删除，当然也可以手动删除。
      • 虽然每个临时节点会绑定到一个客户端会话，但他们对所有客户端还是可见的。
      • 临时节点不允许拥有子节点
    • 持久节点-persistent:
      • 该节点生命周期不依赖于会话
      • 只有客户端显示执行删除操作的时候，他们才能被删除
    • 顺序节点-sequential：
      • 顺序节点可以是持久的，也可以是临时的
      • 当一个新Znode被创建为一个顺序节点，zk通过将10位的序列号附加到原始名称来设置Znode路径

# 原语——定义在Znode上的一组操作

  • 在zookeeper中提供了9种基本操作：
    • create:创建一个Znode节点，父节点必须存在
    • delete:删除一个Znode节点，下面不能有子节点
    • exists:判断一个Znode是否存在，存在时返回元数据
    • getACL:获取Znode的ACL（访问控制列表）
    • setACL:设置Znode的ACL（访问控制列表）
    • getChildren:获取Znode的所有子节点的列表
    • getData:获取子节点的相关数据
    • setData:设置子节点的相关数据
    • sync:使client当前连着的zookeeper服务器和zookeeper的leader节点同步一下数据

# zookeeper的访问权限控制

  • zookeeper的访问权限控制，使用ACL（Access Control List）模式来实现：
    • ACL权限控制，使用“schema:permission”来标识，主要涵盖上方面：
      • 权限模式：鉴权策略，包括world、IP、auth、digest四种
      • 授权对象：权限赋予的用户或者一个实体（授权对象）
      • 权限：CDRWA(create,delete,read,write,admin)（权限类型）

zookeeper的权限控制是基于每一个Znode节点的，需要对每个节点设置权限

每个Znode支持设置多种权限控制方案和多个权限

子节点不会继承父节点权限，客户端无权访问某节点，但可能可以访问它的子节点

# 通知——Watcher机制，用于对分布式应用发送消息

  • zookeeper可以为所有读操作设置watch，这些读操作包括：exists()、getChildren()及getData()
  • watch事件是一次性的触发器，当watch对象状态发生改变时，将会触发此对象所对应的watch事件
  • watch事件将被异步地发送给客户端，并且zookeeper为watch机制提供了有序的一致性保证。理论上客户端接收watch事件的时间要快于其看到watch对象状态变化的时间。
  • zookeeper所管理的watch可以分为两类：
    • 数据watch（data watches）:getData和exists负责设置数据watch
    • 孩子watch（child watches）:getChildren负责设置孩子watch

# zookeeper日常使用

# 文件目录结构

  • bin:
    • 一些主要的运行命令
  • conf:
    • 存放配置文件，其中需要修改的是zoo.cfg，运行zk之前必须配置.cfg。文件中有一个默认的zoo——sample.cfg文件。
  • contrib:
    • 附加的一些功能
  • dist-maven:
    • mvn编译后的目录
  • docs:
    • 文档
  • lib:
    • 需要依赖的jar包
  • recipes:
    • 案例demo的代码
  • src:
    • 源码

# 配置参数

  • tickTime:Client-Server通信心跳时间
    • zookeeper服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个tickTime时间就会发送一个心跳。单位毫秒，默认2000毫秒
  • initLimit:Leader-Follower初始通信时限
    • 集群中的follower服务器（F）与leader服务器（L）之间初始连接能容忍的最多心跳数（tickTime的数量）
  • syncLimit:Leader-Follower同步通信时限
    • 进群中follower服务器与leader服务器之间的请求和响应最多能容忍的心跳数
  • dataDir:数据文件目录
    • 该属性对应的目录是用来存放myid信息跟一些版本，内存数据快照日志，跟服务器唯一的ID信息等
  • clientPort:客户端连接端口
  • maxClientCnxns:允许连接的客户端数据
    • 0位不限制，通过IP来区分不同客户端
  • dataDir:存放事务日志的路径
  • autopurge.snapRetainCount:自动清理保留快照日志的文件数量
  • autopurge.purgeInterval:自动清理使劲间隔，单位小时

# 集群配置

  • 集群配置格式：service.N=YYYY:A:B
    • N：代表服务器编号（也就是myid里的值）
    • YYYY：代表服务器地址
    • A：代表Follow跟Leader通信的端口，简称服务端内部通信端口（默认2888）
    • B：代表选举端口（默认3888）
  • Observer模式配置：service.id=host:port:port:observer

# 高可用

  • 设计
    • zookeeper本身的设计是强一致性的，重点在于数据的同步和一致，而并非是数据高可用性的
  • 高可用
    • zookeeper系统中只要集群中存在超过一半的节点能正常工作，那么整个集群就能正常对外服务（这里的节点指非observer节点）
  • zookeeper选主过程速度很慢
    • zookeeper选主过程通常耗时30~120s，期间由于没有master，所以整个集群是不可用的。对于网络里偶尔出现的，比如半秒一秒的网络隔离，zookeeper会由于选主过程把不可用的回见放大几十倍。
  • 容灾
    • zookeeper的高可用在部署上是很有考量的，zookeeper集群在部署上可以做到机房容灾（3机房），但是做不到异地容灾（异地之间网络比较复杂，容易出现集群重新选主，导致整个集群不可用，而选主时间又很长）。另外，为了提升集群的扩展性和稳定性，可以引入observer节点，提升读性能，保护leader和follow节点。

# 双机房集群部署

  • 双机房集群部署推荐
    • 机房A：
      • leader
      • follower
      • follower
    • 机房B：
      • observer
      • observer
      • observer

# 监控命令

zookeeper3.4.6以后，支持某些特性的四字命令字母与其交互。这些大多是查询命令，用来获取zookeeper的当前状态以及相关信息。用户在客户端通过teInet或nc向zookeeper提-交相应的命令。

命令 示例 描述
conf echo conf | nc localhost 2181 （New in 3.3.0）输出相关服务配置的详细信息。比如端口、zk数据及日志配置路径、最大连接数、session超时时间、serverId等
cons echo cons | nc localhost 2181 （New in 3.3.0）列出所有连接到这台服务器的客户端连接/会话的详细信息。包括“接收/发送”的包数量、session id、操作延迟、最后的操作执行信息。
srvr echo srvr | nc localhost 2181 （New in 3.3.0）输出服务器的详细信息。zk版本、接收/发送包数量、连接数、模式（leader/follower）、节点总数。
stat echo stat | nc localhost 2181 输出服务器的详细信息：接收/发送包数量、连接数、模式（leader/follower）、节点总数、延迟。所有客户端的列表
Last Updated: 5/24/2021, 10:37:17 AM

← zookeeper-分布式锁原理 →