Zookeeper 分布式服务协调治理框架介绍入门

文章目录

  • 为甚么需要Zookeeper
  • [一、Zookeeper 介绍](#一、Zookeeper 介绍)
    • [1.1 介绍](#1.1 介绍)
    • [1.2 Zookeeper中的一些概念](#1.2 Zookeeper中的一些概念)
      • [1.2.1 集群角色](#1.2.1 集群角色)
      • [1.2.2 会话 session](#1.2.2 会话 session)
      • [1.2.3 数据节点 Znode](#1.2.3 数据节点 Znode)
      • [1.2.4 版本](#1.2.4 版本)
      • [1.2.5 事件监听器 Watcher](#1.2.5 事件监听器 Watcher)
      • [1.2.6 ACL 权限控制表(Access Control Lists)](#1.2.6 ACL 权限控制表(Access Control Lists))
  • [二、 Zookeeper的系统模型](#二、 Zookeeper的系统模型)
      • [2.1.1 ZNode节点](#2.1.1 ZNode节点)
      • [2.1.2 ZNode的分类](#2.1.2 ZNode的分类)
      • [2.1.3 事务ID](#2.1.3 事务ID)
      • [2.1.4 ZNode的状态信息](#2.1.4 ZNode的状态信息)
      • [2.1.5 Watcher 数据变更通知](#2.1.5 Watcher 数据变更通知)
      • [2.1.6 ACL 保障数据的安全](#2.1.6 ACL 保障数据的安全)

Zookeeper最主要的使用场景,是作为分布式系统的分布式协同服务

资料:

其他:

  • 3.5支持动态节点扩容,之前要么全部停止,要么一个一个停止更新
  • zookeeper的核心 zab协议,是一个最终一致性的协议,因为除了主节点外其他节点都是异步写入的数据,客户端如果在未同步完成前读取数据,就有可能出现数据不一致。如果要保证强一致性,那么写入性能将大受影响。如过要保证最新的值,那么客户端API提供了sync()方法,读取节点数据前调用一下,节点就会和主节点进行最新的同步。

为甚么需要Zookeeper

分布式系统的信息传输不可靠可能导致信息不一致

分布式系统使用n个服务器组成集群,可以增强系统的计算能力,但是服务器之间的信息传输协调,依靠的是不可靠的网络传输。需要考虑网络延迟、中断、服务器之间的信息不对等等问题。所以需要通过某种方式,让每个服务器之间能够信息同步和共享。
让分布式系统信息同步和共享

  • 方式1:通过网络进行信息共享 通过网络进行信息共享,每次有数据变动时直接通知给每台服务器。出现网络问题的话,可能就会数据不一致,并且后续加入的服务器无法得知之前的消息。
  • **方式2:通过共享存储进行信息共享 **例如对于需要共享的数据,放在可以共享访问的数据库中,各个服务器定期主动拉取数据。
  • 方式2优化 对于需要共享的数据,放在所有服务器都能共享访问的地方。并且当数据发生改变时,主动通知关注的服务器,这样各个服务器都能第一时间获取到最新的数据。Zookeeper 就是这种方式实现的对分布式系统的协调。

一、Zookeeper 介绍

1.1 介绍

zookeeper 是一个开源的**分布式协调服务,**是一个典型的分布式数据一致性的解决方案。实现了分布式数据的强一致性!基于Zookeeper可以实现数据发布/订阅,负载均衡、命名服务、集群管理、分布式锁、分布式队列等功能。

1.2 Zookeeper中的一些概念

1.2.1 集群角色

  • 在通常的集群方式中,最典型的就是Master/Slave模式(主备) ,这种模式对能够处理写操作的机器称为Master通过异步复制获取最新数据的称为Slave机器。
  • Zookeeper没有直接使用M/S模式,引入了Leader、Follower、Observer三种角色。
  • Zookeeper集群中所有机器通过Leader选举,选出Leader、Leader能提供事务写入服务,其他节点则仅提供读取服务,并且负责转发客户端写入事务到Leader节点。
  • Observer和Follower节点的区别就是,Observer节点不参与投票,也不参与选举。Observer类型节点可以提升选举和投票的效率。

1.2.2 会话 session

  • Session指的是客户端会话,zookeeper使用的是基于TCP的自己实现的通信协议。
  • 会话指的就是客户端和服务端之间的一次TCP长连接的创建和销毁。客户端通过这个TCP长连接来和服务器保持有效的会话,也能向服务器发送请求接受响应,同时还能接受来自服务器的Watch事件。

1.2.3 数据节点 Znode

  • 在分布式系统中,"节点"往往是指代一台机器,但是 Zookeeper中,节点可以指代构成集群的机器称为"机器节点 ",另外往往指代zookeeper的一中数据模型的数据单元**,** 称为数据节点。
  • Zookeeper 将所有数据存储在内存中,数据模型是一棵树 ZNode Tree,由斜杠 / 进行分割的路径,就是一个Znode,例如 /lock/app 。每个ZNode可以保存自己的数据内容,同时还会保存一系列属性信息。

1.2.4 版本

  • 每个Znode会存储数据,并且Zookeeper会为其维护一个叫做叫做Stat的数据结构,Stat记录了这个ZNode的三个数据版本。
  • version 指代当前的 Znode 保存的数据内容版本。
  • cversion 指代当前ZNode子节点的版本
  • aversion 当前ZNode的ACL版本

1.2.5 事件监听器 Watcher

Watcher是Zookeeper很重要的特性,Zookeeper允许客户端在指定节点上注册一些Watcher,并且在对应事件触发时主动通知到监听的客户端。这也是Zookeeper实现分布式协调服务的重要特性。

1.2.6 ACL 权限控制表(Access Control Lists)

Zookeeper 使用ACL (Access Control Lists) 策略来进行权限控制其包含了下面五种权限

  1. CREATE 创建子节点的权限
  2. READ 获取子节点和子节点列表的权限
  3. WRITE 更新节点数据的权限
  4. DELETE 删除子节点的权限
  5. ADMIN 设置节点ACL的权限

二、 Zookeeper的系统模型

2.1.1 ZNode节点

  • ZooKeeper中,数据信息被保存在一个个的数据节点上,这些节点称为znode
  • ZNode是Zookeeper中最小的数据单位
  • ZNode一层层可以往下挂Znode,最后形成一颗ZNode树,类似文件系统的层级树状结构。
  • ZNode使用 / 来分割,/ 也表示根目录。

2.1.2 ZNode的分类

ZooKeeper 的节点类型可以分为三类

  • 持久性节点 Presistent 是Zookeeper中最常见的一种节点类型,节点被创建后除非主动删除否则会一直存在ZooKeeper服务中。
  • 临时性节点 Ephemeral 会被自动清理的节点,生命周期和客户端会话绑定,一旦会话结束节点就会被删除。并且临时节点无法再创建子节点。
  • 顺序节点 Sequential 顺序节点也分为临时顺序节点和持久顺序节点,顺序节点在创建后,会自动加上数字后缀,能体现节点的顺序。

2.1.3 事务ID

  • 什么是事务:这里的事务不是指数据库的事务而是指能够改变ZooKeeper服务器状态的操作。称之为 实务操作,或者更新操作,一般包含数据节点的创建、删除、更新等等。
  • 对于每一个事务请求,ZooKeeper 都会为其分配一个全局唯一的事务ID
  • 事务ID用ZXID来标识,通常是一个64位的数字,每一个ZXID对应一次更新操作,从这些XZID中可以间接的识别出ZooKeeper处理这些更新操作请求的全局顺序。

2.1.4 ZNode的状态信息

bash 复制代码
[zk: localhost:15881(CONNECTED) 8] stat /zk-premament
cZxid = 0x100000006
ctime = Fri Jun 30 11:02:24 CST 2023
mZxid = 0x100000008
mtime = Fri Jun 30 11:03:38 CST 2023
pZxid = 0x100000006
cversion = 0
dataVersion = 1
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 3
numChildren = 0
  • 查看ZNode的状态 stat /zk-premament
  • cZxid Create ZXID 节点被创建时的事务ID
  • ctime Create Time 标识节点创建的事件
  • mZxid Modified ZXID 节点最后一次被修改时的事务ID
  • mtime Modified Time 节点最后一次被修改的事件
  • pZxid 子节点列表最后一次被更新时的事务ID。注意子节点内容变化这个id不会改变。
  • cversion 标识子节点的版本号
  • dataVersion 表示节点内容版本号
  • acVersion 表示acl策略版本号
  • ephemeralOwner 表示创建该临时节点的会话 sessionId 如果是持久性节点那么值为0
  • dataLength 表示数据长度
  • numChildren 表示直系子节点数

2.1.5 Watcher 数据变更通知

  • ZooKeeper使用Watcher机制实现了分布式数据发布/订阅功能
  • 在 ZooKeeper 中,引⼊了 Watcher 机制来实现这种分布式的通知功能。ZooKeeper 允许客户端向服务端注册⼀个 Watcher 监听,当服务端的⼀些指定事件触发了这个 Watcher,那么就会向指定客户端发送⼀个事件通知来实现分布式的通知功能。
  • Zookeeper的Watcher机制主要包括客户端线程客户端WatcherManagerZookeeper服务器三部分
  • 具体⼯作流程为:
    1. 客户端在向Zookeeper服务器注册的同时,会将Watcher对象存储在客户端的WatcherManager当中。
    2. 当Zookeeper服务器触发Watcher事件后,会向客户端发送通知,客户端线程从WatcherManager中取出对应的Watcher对象来执⾏回调逻辑。

2.1.6 ACL 保障数据的安全

Zookeeper作为⼀个分布式协调框架,其内部存储了分布式系统运⾏时状态的元数据,这些元数据会直接影响基于Zookeeper进⾏构造的分布式系统的运⾏状态,因此,如何保障系统中数据的安全,从⽽避免因误操作所带来的数据随意变更⽽导致的数据库异常⼗分重要,在Zookeeper中,提供了⼀套完善的ACL(Access Control List)权限控制机制来保障数据的安全。

  • 我们可以从三个⽅⾯来理解ACL机制:
    • 权限模式(Scheme)
    • 授权对象(ID)
    • 权限(Permission),
  • 通常使⽤"scheme: id : permission"来标识⼀个有效的ACL信息。

**权限模式 Scheme **

用来确定权限验证过程中使用的检验策略,可以分成IP/IP段和账号密码,细分的话可以分为如下四种。

  1. IP 通过ip地址的粒度来进行权限控制,可以配置某个IP也可以配置某个ip网段。
  2. **Digest **是最常用的权限控制模式,更符合我们对权限控制的认识,使用"username:password"形式的权限标识来进行权限配置,可以区分不同的应用来进行权限控制。当我们通过username:password"配置了权限标识后,Zookeper会对其进行SHA-1加密和BASE64编码
  3. **World **是一种开放的权限控制模式,即数据节点的权限对所有用户开放。也可以看成Digest的一种特殊形式。即 "world:anyone"
  4. super 就是超级用户授权,启动zookeeper时修改zkServer.sh的启动命令脚本开启super模式,登录后添加超级管理员账户即可操作管理所有节点。
  5. **Auth **授权用户,用户名:密码 ,需要先添加ACL账户
bash 复制代码
#1添加ACL账户
# addauth digest 用户名:密码
[zk: localhost:2181(CONNECTED) 4] addauth digest test:test123

#2创建测试节点
# create 测试节点 测试节点值
[zk: localhost:2181(CONNECTED) 3] create /test_acl value_of_test_acl

#3给测试节点设置Auth权限
# setAcl 测试节点 auth:用户名:crawd (权限)
[zk: localhost:2181(CONNECTED) 5] setAcl /test_acl auth:test:crawd
bash 复制代码
#第一步:将要设置的密码进行base64编码可以使用linux命令,也可以使用其他语言自己实现
>>echo -n test:test | openssl dgst -binary -sha1 | openssl base64
>>V28q/NynI4JI3Rk54h0r8O5kMug=

#第二步:创建测试节点
[zk: localhost:2181] create /digest user
#第三步:给节点设置 digest授权
[zk: localhost:2181] setAcl /digest digest:test:V28q/NynI4JI3Rk54h0r8O5kMug==:rwadc
#第四步:查询ACL
[zk: localhost:2181] getAcl /digest
#ACL输出结果
[zk: localhost:2181] addauth digest user:passwd
bash 复制代码
#开启SuperDigest超级管理员举例 
 
#1、修改zkServer.sh,加入super权限设置
SUPER_ACL="-Dzookeeper.DigestAuthenticationProvider.superDigest=super:gG7s8t3oDEtIqF6DM9LlI/R+9Ss="
 
#2、重新启动Zookeeper
# ./zkServer.sh restart
 
# 添加认证前无法访问节点
[zk: localhost:2181] ls /test
Authentication is not valid : /test

#3、使用super:super进行认证,添加super认证
[zk: localhost:2181) ] addauth digest super:super
#获得了节点权限
[zk: localhost:2181) ] ls /test
[]
[zk: localhost:2181)] get /test

权限ID

就是权限模式对应的内容,例如权限模式是IP那么对应的ID就是IP地址或网段

**权限Permission **

zookeeper中权限可以分为五大类

  • CREATE(C):数据节点的创建权限,允许授权对象在该数据节点下创建⼦节点
  • DELETE(D):⼦节点的删除权限,允许授权对象删除该数据节点的⼦节点。
  • READ(R):数据节点的读取权限,允许授权对象访问该数据节点并读取其数据内容或⼦节点列表等。
  • WRITE(W):数据节点的更新权限,允许授权对象对该数据节点进⾏更新操作。
  • ADMIN(A):数据节点的管理权限,允许授权对象对该数据节点进⾏ ACL 相关的设置操作。
相关推荐
是芽芽哩!3 小时前
【Kubernetes 指南】基础入门——Kubernetes 基本概念(二)
云原生·容器·kubernetes
SelectDB3 小时前
Apache Doris 创始人:何为“现代化”的数据仓库?
大数据·数据库·云原生
m0_663234013 小时前
云原生是什么
云原生
weisian1514 小时前
Redis篇--常见问题篇7--缓存一致性2(分布式事务框架Seata)
redis·分布式·缓存
不能只会打代码4 小时前
Java并发编程框架之综合案例—— 分布式日志分析系统(七)
java·开发语言·分布式·java并发框架
Elastic 中国社区官方博客4 小时前
如何通过 Kafka 将数据导入 Elasticsearch
大数据·数据库·分布式·elasticsearch·搜索引擎·kafka·全文检索
马剑威(威哥爱编程)5 小时前
分布式Python计算服务MaxFrame使用心得
开发语言·分布式·python·阿里云
运维小文6 小时前
K8S中的服务质量QOS
云原生·容器·kubernetes
华为云开发者联盟6 小时前
Karmada v1.12 版本发布!单集群应用迁移可维护性增强
云原生·kubernetes·开源·容器编排·karmada