网站运营每天做的/怎么自己做一个网站
目录
- 1. 什么是ZooKeeper?
- 2. 为什么要用ZooKeeper
- 3. ZooKeeper应用初体验
- 3.1 zkCli命令行
- 3.2 Java API编程
- 4.基本概念和操作
- 4.1 ZooKeeper数据结构
- 4.2 数据节点ZNode
- 4.3 会话(Session)
- 4.4 请求
- 4.5 事务zxid
- 4.6 Watcher监视器
- 5. ZooKeeper工作原理
- 6. ZooKeeper应用场景
- 7. 访问控制ACL
- 7.1 为什么要用ACL
- 7.2 何为ACL
- 7.3 schema
- 7.4 id
- 7.5 permission ACL种类
- 7.6 ACL 相关命令
- 7.7 设置acl
1. 什么是ZooKeeper?
- 是Google的Chubby的一个开源实现版
- ZooKeeper
- 一个主从架构的分布式框架、开源的
- 对其他的分布式框架的提供协调服务(service)
- Zookeeper 作为一个分布式的服务框架
- 它提供类似于linux文件系统(有目录节点树)的简版文件系统来存储数据
- Zookeeper 维护和监控存储的数据的状态变化,通过监控这些数据状态的变化,从而达到基于数据的集群管理
- 主要用来解决分布式集群中应用系统的一致性问题
2. 为什么要用ZooKeeper
-
分布式框架多个独立的程序协同工作比较复杂
- 开发人员容易花较多的精力实现如何使多个程序协同工作的逻辑
- 导致没有时间更好的思考实现程序本身的逻辑
- 或者开发人员对程序间的协同工作关注不够,造成协调问题
- 且分布式框架中协同工作的逻辑是共性的需求
-
ZooKeeper简单易用,能够很好的解决分布式框架在运行中,出现的各种协调问题。
- 比如集群master主备切换、节点的上下线感知、统一命名服务、状态同步服务、集群管理、分布式应用配置管理等等
3. ZooKeeper应用初体验
ZooKeeper集群也是主从架构的:leader为主;follower为从
通过客户端操作ZooKeeper集群,有两种类型的客户端
①命令行zkCli
②Java编程
3.1 zkCli命令行
- 集群命令(每个节点运行此命令)
# 启动ZooKeeper集群;在ZooKeeper集群中的每个节点执行此命令
${ZK_HOME}/bin/zkServer.sh start
# 停止ZooKeeper集群(每个节点执行以下命令)
${ZK_HOME}/bin/zkServer.sh stop
# 查看集群状态(每个节点执行此命令)
${ZK_HOME}/bin/zkServer.sh status
- 客户端连接zkServer服务器
# 使用ZooKeeper自带的脚本,连接ZooKeeper的服务器:2181端口是zoo.cfg中clientPort指定的客户端与服务器通信的端口
zkCli.sh -server node01:2181,node02:2181,node03:2181
-server选项后指定参数node01:2181,node02:2181,node03:2181
客户端随机的连接三个服务器中的一个
-
客户端发出对ZooKeeper集群的读写请求
- ZooKeeper集群中有类似于linux文件系统的一个简版的文件系统;目录结构也是树状结构(目录树)
- 重要技巧:不会就喊help
- 还记得其它框架中help的使用吗?
- 常用命令
#查看ZooKeeper根目录/下的文件列表
ls /
#创建节点,并指定数据
create /kkb kkb
#获得某节点的数据
get /kkb
get -s /kkb
#修改节点的数据
set /kkb kkb01#删除节点
delete /kkb
3.2 Java API编程
IDE可以是eclipse,或IDEA;此处以IDEA演示
编程分两类:原生API编程;curator编程
- [Curator官网](< http://curator.apache.org/ >)
- Curator编程
- Curator对ZooKeeper的api做了封装,提供简单易用的api;
- 它的风格是Curator链式编程
- 相关依赖
代码:
https://github.com/chenruoyu0319/ZooKeeper.git
4.基本概念和操作
分布式通信有几种方式
1、直接通过网络连接的方式进行通信
2、通过共享存储的方式,来进行通信或数据的传输
ZooKeeper使用第二种方式,提供分布式协调服务
4.1 ZooKeeper数据结构
ZooKeeper主要由以下三个部分实现
ZooKeeper=①简版文件系统(Znode)+②原语+③通知机制(Watcher)。
- ZK文件系统
- 基于类似于文件系统的目录节点树方式的数据存储
- 原语
- 可简单理解成ZooKeeper的基本的命令
- Watcher(监听器)
4.2 数据节点ZNode
4.2.1 什么是ZNode
- ZNode 分为四类:
持久节点 | 临时节点 | |
---|---|---|
非有序节点 | create | create -e |
有序节点 | create -s | create -s -e |
4.2.2 持久节点
- 类比,文件夹
# 创建节点/zk_test,并设置数据my_data
create /zk_test my_data
# 持久节点,只有显示的调用命令,才能删除永久节点
delete /zk_test
4.2.3 临时节点
- 临时节点的生命周期跟客户端会话session绑定,一旦会话失效,临时节点被删除。
# client1上创建临时节点
create -e /tmp tmpdata# client2上查看client1创建的临时节点
ls /# client1断开连接
close# client2上观察现象,发现临时节点被自动删除
ls /
4.2.4 有序节点
-
ZNode也可以设置为有序节点
-
为什么设计有序节点?
-
防止多个不同的客户端在同一目录下,创建同名ZNode,由于重名,导致创建失败
-
如何创建有序节点
-
命令行使用-s选项:create -s /kkb kkb
-
Curator编程,可添加一个特殊的属性:CreateMode.PERSISTENT_SEQUENTIAL
-
-
一旦节点被标记上这个属性,那么在这个节点被创建时,ZooKeeper 就会自动在其节点后面追加上一个整型数字
- 这个整数是一个由父节点维护的自增数字。
- 提供了创建唯一名字的ZNode的方式
# 创建持久、有序节点 create -s /test01 test01-data # Created /test010000000009
4.3 会话(Session)
Session的本质:TCP长连接
4.4.1 什么是会话
-
客户端要对ZooKeeper集群进行读写操作,得先与某一ZooKeeper服务器建立TCP长连接;此TCP长连接称为建立一个会话Session。
-
每个会话有超时时间:SessionTimeout
- 当客户端与集群建立会话后,如果超过SessionTimeout时间,两者间没有通信,会话超时
4.4.2 会话的特点
- 客户端打开一个Session中的请求以FIFO(先进先出)的顺序执行;
- 如客户端client01与集群建立会话后,先发出一个create请求,再发出一个get请求;
- 那么在执行时,会先执行create,再执行get
- 若打开两个Session,无法保证Session间,请求FIFO执行;只能保证一个session中请求的FIFO
4.4.3 会话的生命周期
- 会话的生命周期
- 未建立连接
- 正在连接
- 已连接
- 关闭连接
4.4 请求
- 读写请求
- 通过客户端向ZooKeeper集群中写数据
- 通过客户端从ZooKeeper集群中读数据
4.5 事务zxid
-
事务
- 客户端的写请求,会对ZooKeeper中的数据做出更改;如增删改的操作
- 每次写请求,会生成一次事务
- 每个事务有一个全局唯一的事务ID,用 ZXID 表示;全局自增
-
事务特点
- ACID:
- 原子性atomicity | 一致性consistency | 隔离性isolation | 持久性durability
-
ZXID结构:
- 通常是一个64位的数字。由epoch+counter组成
- epoch、counter各32位
4.6 Watcher监视器
4.6.1 为什么要有Watcher
- 问:客户端如何获取ZooKeeper服务器上的最新数据?
- 方式一轮询:ZooKeeper以远程服务的方式,被客户端访问;客户端以轮询的方式获得znode数据,效率会比较低(代价比较大)
- 方式二基于通知的机制:
- 客户端在znode上注册一个Watcher监视器
- 当znode上数据出现变化,watcher监测到此变化,通知客户端
- 对比,那种好?
4.6.2 什么是Watcher?
- 客户端在服务器端,注册的事件监听器;
- watcher用于监听znode上的某些事件
- 比如znode数据修改、节点增删等;
- 当监听到事件后,watcher会触发通知客户端
4.6.3 如何设置Watcher
注意:Watcher是一个单次触发的操作
- 可以设置watcher的命令如下:
- 示例1
#node01 上执行
#ls [-w] path
ls -w /zk_test#node02 上执行
create /zk_test/dir01 dir01-data#观察node-01上变化
[zk: node01:2181,node02:2181,node03:2181(CONNECTED) 22]
WATCHER::WatchedEvent state:SyncConnected type:NodeChildrenChanged path:/zk_test
图示:
- client1上执行步骤1
- client2上执行步骤2;
- client1上观察现象3
- 示例2
# 监控节点数据的变化;
# node01上
# get [-s] [-w] path
get -w /zk_test#node02上
set /zk_test "junk01"
#观察node2上cli的输出,检测到变化
[zk: node01:2181,node02:2181,node03:2181(CONNECTED) 23]
WATCHER::WatchedEvent state:SyncConnected type:NodeDataChanged path:/zk_test
-
示例3:节点上下线监控
-
原理:
- 节点1(client1)创建临时节点
- 节点2(client2)在临时节点,注册监听器watcher
- 当client1与zk集群断开连接,临时节点会被删除
- watcher发送消息,通知client2,临时节点被删除的事件
-
用到的zk特性:
Watcher+临时节点
-
好处:
通过这种方式,检测和被检测系统不需要直接关联(如client1与client2),而是通过ZK上的某个节点进行关联,大大减少了系统耦合。
-
实现:
client1操作
# 创建临时节点 create -e /zk_tmp tmp-data
client2操作
# 在/zk_tmp注册监听器 ls -w /zk_tmp
client1操作
# 模拟节点下线 close
观察client2
[zk: node01:2181,node02:2181,node03:2181(CONNECTED) 3] WATCHER::WatchedEvent state:SyncConnected type:NodeDeleted path:/zk_tmp
-
5. ZooKeeper工作原理
- ZooKeeper使用原子广播协议叫做Zab(ZooKeeper Automic Broadcast)协议
- Zab协议有两种模式
- 恢复模式(选主):因为ZooKeeper也是主从架构;当ZooKeeper集群没有主的角色leader时,从众多服务器中选举leader时,处于此模式
- 广播模式(同步):当集群有了leader后,客户端向ZooKeeper集群读写数据时,集群处于此模式
- 为了保证事务的顺序一致性,ZooKeeper采用了递增的事务id号(zxid)来标识事务,所有提议(proposal)都有zxid
6. ZooKeeper应用场景
- ZooKeeper应用场景
- NameNode使用ZooKeeper实现高可用.
- Yarn ResourceManager使用ZooKeeper实现高可用.
- 利用ZooKeeper对HBase集群做高可用配置
- kafka使用ZooKeeper
- 保存消息消费信息比如offset.
- 用于检测崩溃
- 主题topic发现
- 保持主题的生产和消费状态
7. 访问控制ACL
7.1 为什么要用ACL
- zk做为分布式架构中的重要中间件,通常会在上面以节点的方式存储一些关键信息,默认情况下,所有应用都可以读写任何节点,在复杂的应用中,这不太安全,ZK通过ACL机制来解决访问权限问题
7.2 何为ACL
-
ACL(Access Control List)可以设置某些客户端,对zookeeper服务器上节点的权限,如增删改查等
-
ACL 权限控制,使用:
scheme:id:perm
来标识,主要涵盖 3 个方面:- 权限模式(Scheme):授权的策略
- 授权对象(ID):授权的对象
- 权限(Permission):授予的权限
7.3 schema
- 鉴权模式
- world:默认方式,相当于全世界都能访问
- auth:代表已经认证通过的用户(cli中可以通过addauth digest user:pwd 来添加当前上下文中的授权用户)
- digest:即用户名:密码这种方式认证,这也是业务系统中最常用的;用 username:password 字符串来产生一个MD5串,然后该串被用来作为ACL ID。认证是通过明文发送username:password 来进行的,当用在ACL时,表达式为username:base64 ,base64是password的SHA1摘要的编码。
- ip:使用客户端的主机IP作为ACL ID 。这个ACL表达式的格式为addr/bits ,此时addr中的有效位与客户端addr中的有效位进行比对。
7.4 id
- 授权对象ID是指,权限赋予的用户或者一个实体,例如:IP 地址或者机器。授权模式 schema 与 授权对象 ID 之间
7.5 permission ACL种类
ZooKeeper 采用 ACL(Access Control Lists)策略来进行权限控制。ZooKeeper 定义了如下5种权限。
-
CREATE: 创建子节点的权限。
-
READ: 获取节点数据和子节点列表的权限。
-
WRITE:更新节点数据的权限。
-
DELETE: 删除子节点的权限。
-
ADMIN: 设置节点ACL的权限。
注意:CREATE 和 DELETE 都是针对子节点的权限控制。
五种权限简称
- CREATE -> 增 -> c
- READ -> 查 -> r
- WRITE -> 改 -> w
- DELETE -> 删 -> d
- ADMIN -> 管理 -> a
- 这5种权限简写为crwda
7.6 ACL 相关命令
-
addauth scheme auth 添加认证用户
-
getAcl [-s] path 读取ACL权限
-
setAcl [-s] [-v version] [-R] path acl 设置ACL权限
7.7 设置acl
- word 权限模式
[zk: node01:2181,node02:2181(CONNECTED) 29] create /testauth authdata
Created /testauth
[zk: node01:2181,node02:2181(CONNECTED) 30] getAcl /testauth
'world,'anyone
: cdrwa
[zk: node01:2181,node02:2181(CONNECTED) 31] setAcl /testauth world:anyone:acd
[zk: node01:2181,node02:2181(CONNECTED) 32] set /testauth newdata
Authentication is not valid : /testauth
- auth权限模式
[zk: node01:2181,node02:2181(CONNECTED) 33] create /authschema data
Created /authschema
#增加授权用户,明文用户名和密码
[zk: node01:2181,node02:2181(CONNECTED) 34] addauth digest hadoop:123456
#授予权限
[zk: node01:2181,node02:2181(CONNECTED) 35] setAcl /authschema auth:hadoop:cdwra
[zk: node01:2181,node02:2181(CONNECTED) 36]
[zk: node01:2181,node02:2181(CONNECTED) 36] close
#再次登录,需要添加授权用户
[zk: node01:2181,node02:2181(CONNECTED) 38] get /authschema # 没有权限
org.apache.zookeeper.KeeperException$NoAuthException: KeeperErrorCode = NoAuth for /authschema
#添加授权用户
[zk: node01:2181,node02:2181(CONNECTED) 39] addauth digest hadoop:123456
#添加过授权用户后,可以获得/authschema数据
[zk: node01:2181,node02:2181(CONNECTED) 40] get /authschema
data
- ip权限模式
[zk: node01:2181,node02:2181(CONNECTED) 41] create /ipschema data
Created /ipschema
#修改此ip的具有的权限
[zk: node01:2181,node02:2181(CONNECTED) 42] setAcl /ipschema ip:127.0.0.1:crwd
#也可以设置多个ip
[zk: node01:2181,node02:2181(CONNECTED) 44] create /ipschema1 data
Created /ipschema1
[zk: node01:2181,node02:2181(CONNECTED) 46] setAcl /ipschema1 ip:127.0.0.1:crwda,ip:192.168.77.100:crwda
- digest权限模式
setAcl /test digest:用户名:密码:权限
密码是用户名和密码加密后的字符串用代码将用户名、密码字符串加密
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;
import org.apache.commons.codec.binary.Base64;public class Test {public static void main(String[] args) throws NoSuchAlgorithmException {String usernameAndPassword = "spark:123456";//生成密码:sha1加密之后base64编码byte digest[] = MessageDigest.getInstance("SHA1").digest(usernameAndPassword.getBytes());Base64 base64 = new Base64();String encodeToString = base64.encodeToString(digest);System.out.println(encodeToString);//s73bPZjm3V8zIIO/SbaLwnJJmok=}
}
设置权限
#创建znode节点
[zk: node01:2181,node02:2181,node03:2181(CONNECTED) 2] create /digestschema data
Created /digestschema
#设置acl
[zk: node01:2181,node02:2181,node03:2181(CONNECTED) 4] setAcl /digestschema digest:spark:s73bPZjm3V8zIIO/SbaLwnJJmok=:crwda
#权限不足
[zk: node01:2181,node02:2181,node03:2181(CONNECTED) 5] getAcl /digestschema
Authentication is not valid : /digestschema
#增加认证用户
[zk: node01:2181,node02:2181,node03:2181(CONNECTED) 6] addauth digest spark:123456
#现已有权限获得znode数据,及删除znode
[zk: node01:2181,node02:2181,node03:2181(CONNECTED) 7] getAcl /digestschema
'digest,'spark:s73bPZjm3V8zIIO/SbaLwnJJmok=
: cdrwa
[zk: node01:2181,node02:2181,node03:2181(CONNECTED) 8] ls /
[authschema, digestschema, ipschema, ipschema1, kkb, testauth, zk_test, zookeeper]
[zk: node01:2181,node02:2181,node03:2181(CONNECTED) 9] delete /digestschema
[zk: node01:2181,node02:2181,node03:2181(CONNECTED) 10] ls /
[authschema, ipschema, ipschema1, kkb, testauth, zk_test, zookeeper]