ZooKeeper-SGG笔记
- ZooKeeper工作机制
Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。
![image]()
- ZooKeeper特点
![image]()
1）Zookeeper：一个领导者（Leader），多个跟随者（Follower）组成的集群。
2）集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。所以Zookeeper适合安装奇数台服务器。
3）全局数据一致：每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据都是一致的。
4）更新请求顺序执行，来自同一个Client的更新请求按其发送顺序依次执行。
5）数据更新原子性，一次数据更新要么成功，要么失败。（类似于SQL的事务）
6）实时性，在一定时间范围内，Clicnt能读到最新数据。（同步时间非常快）
- ZooKeeper数据结构
ZooKeeper 数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。每一个ZNode默认能够存储1MB的数据，每个ZNode.都可以通过其路径唯一标识。
![image]()
- ZooKeeper应用场景
提供的服务包括：统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等。
-
统一命名服务
![image]()
在分布式环境下，经常需要对应用/服务进行统一命名，便于识别。
例如：IP不容易记住，而域名容易记住。
有几台服务器故障了也无所谓 -
统一配置管理
![image]()
1）分布式环境下，配置文件同步非常常见。
（1）一般要求一个集群中，所有节点的配置信息是一致的，比如Kafka集群。
（2）对配置文件修改后，希望能够快速同步到各个节点上。
2）配置管理可交由ZooKeeper实现。
（1）可将配置信息写入ZooKeeper上的一个Znode。
（2）各个客户端服务器监听这个Znode。一旦发生变化就通知更新 -
统一集群管理
![image]()
1）分布式环境中，实时掌握每个节点的状态是必要的。
（1）可根据节点实时状态做出一些调整。
2）ZooKeeper可以实现实时监控节点状态变化（1）可将节点信息写入ZooKeeper上的一个ZNode。
（2）监听这个ZNode可获取它的实时状态变化。 -
服务器动态上下线
![image]()
-
软负载均衡
![image]()
在Zookeeper中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求
- 配置参数解读
Zookeeper中的配置文件zoo.cfg中参数含义解读如下：
1）tickTime=2000：通信心跳时间，Zookeeper服务器与客户端心跳时间，单位毫秒
![image]()
就是过段时间证明你还活着
2）initLimit=10：LF初始通信时限
![image]()
Leader和Follower初始连接时能容忍的最多心跳数（tickTime的数量），就是初始化的时候如果这么多个心跳时间还没有链接上就是链接失败了
3）syncLimit=5：LF同步通信时限
![image]()
初始化链接好之后的下次链接，Leader和Follower之间通信时间如果超过syncLimit*tickTime，Leader认为Follwer死掉，从服务器列表中删除Follwer。
4）dataDir：保存Zookeeper中的数据注意：默认的tmp目录，容易被Linux系统定期删除，所以一般不用默认的tmp目录。
5）clientPort=2181：客户端连接端口，通常不做修改。
以下换成kx架构
- ls / 查看节点** 注意zk中节点包含了数据和节点信息**
- create 创建节点时必须输入值
- 节点的种类
- 持久节点
客户端连接断开后，数据（znode） - 临时节点
客户端断开后，数据（znode）不在 - 持久节点/临时节点创建重名时会报错
- 顺序节点创建重名时不会报错，只会自增1
- 节点的状态属性
序号|属性|描述
1 czxid 节点被创建的事务ID值
2 mzxid long节点被修改的事务ID值
3 pzxid 子节点最近一次被修改时的事务ID
- 事务ID可以识别出请求的全局顺序
4 ctime 节点被创建的时间
5 mtime 节点最后一次被修改的时间
6 versoin 节点被修改的版本号（该节点每次被修改就+1）
7 cversion 节点的所拥有子节点被修改的版本号
8 aversion 节点的ACL被修改的版本号 - 版本号的作用：基于CAS理论保证分布式数据原子性操作
9 emphemeralowner 如果此节点为临时节点，那么它的值为这个节点拥有者的会话ID；否则，它的值为0
10 datalength 节点数据域的长度
11 numchildren 节点拥有的子节点个数
- 服务端的常用指令
1.启动ZK服务：sh ./zkServer.sh start
2.查看ZK服务状态：sh ./zkServer.sh status
3.停止ZK服务：sh ./zkServersh stop
4.重启ZK服务：sh ./zkServer.sh restart
- 客户端的常用指令
使用zkCli.sh-server 127.0.0.1：2181连接到ZooKeeper服务，连接成功后，系统会输出ZooKeeper的相关环境以及配置信息。命令行工具的一些简单操作如下：
1.显示根目录下、文件：Is/使用Is命令来查看当前ZooKeeper中所包含的内容
2.显示根目录下、文件：1s2/查看当前节点数据并能看到更新次数等数据
3.创建文件，并设置初始内容：create/zk"test”创建一个新的znode节点“zk"以及与它关联的字符串（-e临时节点 -s顺序节点）
4.获取文件内容：get/zk确认znode是否包含我们所创建的字符串
5.修改文件内容：set/zk"zkbak"对zk所关联的字符串进行设置
6.删除文件：delete/zk将刚才创建的znode 删除，如果存在子节点删除失败
7.递归删除：rmr/zk将刚才创建的znode 删除，子节点同时删除
8.退出客户端：quit（退出后临时节点就没了）
9.帮助命令：help
- ACL保障数据的安全（平时不用，面试用）
ACL机制，表示为scheme🆔permissions（通过getAcl获得），第一个字段表示采用哪一种机制，第二个id表示用户，permissions表示相关权限（如只读，读写，管理等）。zookeeper提供了如下几种机制（scheme）：
- world：它下面只有一个id，叫anyone，world:anyone代表任何人，zookeeper中对所有人有权限的结点就是属于world:anyone的
- auth：它不需要id，只要是通过authentication的user都有权限（可以通过addauth digest user:pwd 来添加授权用户）
- digest：即用户名：密码这种方式认证，这也是业务系统中最常用的
- ip：它对应的id为客户机的IP地址，设置的时候可以设置一个ip段，比如ip：192.168.1.
0/16，表示匹配前16个bit的IP段
world后面的id只能是anyone
auth后面是username:password
digest后面是username:BASE64(SHA1(password))
ip后面是限制链接的客户端ip
权限：（cdrwa）：
create（c）：是否有创建节点的权限
detete（d）：是否有删除节点的权限
read（r）：是否有读取数据的权限
write（w）：修改节点的数据权限
admin（a）：是否有给子节点设置权限的权力
- ACL常用命令
- getAcl 获取指定节点的ACL信息
- setAcl 设置指定节点的ACL信息
- addauth 注册会话授权信息
setAcl使用示例：
setAc1 /testpir/testAcl world:anyone:crwa
addauth使用示例：
addauth digest user1：123456相当于给当前的会话增加了一个user1而且密码是123456再crud：addauth digest userl:123456
密文的话是在DigestAuthenticationProvider类当中转换的。
- ZooKeeper常用四字命令（基本用不到）
ZooKeeper 支持某些特定的四字命令字母与其的交互。用来获取ZooKeeper服务的当前状态及相关信息。可通过telnet或nc向ZooKeeper 提交相应的命令：
- echo stat|nc 127.0.0.12181来查看哪个节点被选择作为follower或者leader
- 使用echo ruok|nc 127.0.0.12181测试是否启动了该Server，若回复imok表示已经启动。
- echo dumpl nc 127.0.0.12181，列出未经处理的会话和临时节点。
- echo kill |nc 127.0.0.12181，关掉server
- echo conf |nc 127.0.0.12181，输出相关服务配置的详细信息。
- echo cons|nc 127.0.0.12181，列出所有连接到服务器的客户端的完全的连接/会话的详细信息
- echo envi | nc 127.0.0.12181，输出关于服务环境的详细信息（区别于conf命令）。
- echo reqs |nc 127.0.0.12181，列出未经处理的请求。
- echo wchs |nc 127.0.0.1 2181，列出服务器watch的详细信息。
- echo wchc |nc 127.0.0.1 2181，通过 session 列出服务器 watch 的详细信息，它的输出是一个与watch相关的会话的列表。
- echo wchp |nc 127.0.0.1 2181，通过路径列出服务器 watch的详细信息。它输出一个与session相关的路径。
- ZooKeeper日志可视化
ZK中的快照和日志都是2进制的，需要转换
- 事务日志可视化（LogFormatter）
java-cp.…/../zookeeper-3.4.6.jar；.…/../1ib/s1f4j-api-1.6.1.jar lorg.apache.zookeeper.server.LogFormatter 1og.xxxx - 数据快照可视化（SnapshotFormatter）
java-cp…/../zookeeper-3.4.6.jar；../../1ib/s1f4j-api-1.6.1.jar org.apache.zookeeper.server.SnapshotFormatter snapshot.xxxx
- ZooKeeper原生客户端(ZK官方提供的java客户端API)
1.创建会话
public Zookeeper（String connectString，int sessionTimeout，Watcher watcher，
1ong sessionId，byte[]sessionPasswd，boolean canBeReadonly）
2.创建节点
public string/void create（final String path，byte data[]，Listacl，CreateMode createMode，Stringcallback cb，object ctx）
3.读取数据
public List/void getChildren（final String path，Watcher watcher，Stat stat，Children2Callback cb，Object ctx）
public List/void getData（final String path，Watcher watcher，Stat stat，DataCallback cb，Object ctx）
4.更新数据
public Stat/void setData（final String path，byte data[]，int version，Statcallback cb，object ctx）
5.检测节点是否存在
public Stat/void exists（final String path，Watcher watcher，Statcallback cb，object ctx）
6.权限控制
public void addAuthInfo（String scheme，byte auth[]）
7.watch org.apache.zookeeper.Watcher（KeeperState、EventType）
（1）没有专门的API去注册watcher.依附于增删改查API；
（2）watch是次性产品
（3）watch的process方法中，可对不同事件进行处理； - 在使用watch对节点数据是否改变做监听的时候，必须先get一下，让watch=true，否则不会触发监听，而且只能触发一次，之后又要true或者设置新的watch
- ZooKeeper的Curator操作
- Curator采用Fluent风格API
<！--curator依赖-->
org.apache.curator
curator-framework
4.0.0
- 事务支持（保证一组操作的原子性）
Co1lectionresults=
client.transaction().forOperations(operations); - 异步支持
引入BackgroundCallback接口，用于处理异步接口调用之后服务端返回的结果信息
public void proces sResult（CuratorFramework client，CuratorEvent event）
·CuratorEventType事件类型
·org.apache.zookeeper.KeeperException.Code 服务器响应码（标识结果）
浙公网安备 33010602011771号