zookeeper工作原理与节点使用

目录

zookeeper集群的搭建：

配置解释：

特点：

常规搭建方式，进行操作：

A.关闭防火墙（测试环境）

B.启动 服务，每个规划的 zookeeper 节点都要进行启动

C.启动客户端

D.命令使用

1. help

2. ls 查看当前存在的根目录

3. znode 节点

4. create 创建节点

a. 创建临时节点，获得临时节点的数据

b.创建持久化节点，获得临时节点的数据

c.创建子节点

d.创建孙子节点

e.znode节点数据结构

E.数据同步

恢复模式

广播模式

---

zookeeper集群的搭建：

1. 常规的搭建（推荐）  https://blog.csdn.net/yang_zzu/article/details/108199608#t5

2. docker 容器搭建 https://blog.csdn.net/yang_zzu/article/details/105618204

 

配置解释：

tickTime：发送心跳的间隔时间，单位：毫秒
dataDir：zookeeper保存数据的目录。
clientPort：客户端连接 Zookeeper 服务器的端口，Zookeeper  会监听这个端口，接受客户端的访问请求。
initLimit： 这个配置项是用来配置 Zookeeper 接受客户端（这里所说的客户端不是用户连  接 Zookeeper 服务器的客户端，而是 Zookeeper 服务器集群中连接到 Leader 的  Follower 服务器）初始化连接时最长能忍受多少个心跳时间间隔数。当已经超过 5 个心跳的  时间（也就是 tickTime）长度后 Zookeeper 服务器还没有收到客户端的返回信息，那么表  明这个客户端连接失败。总的时间长度就是 5*2000=10 秒
syncLimit：这个配置项标识 Leader 与 Follower 之间发送消息，请求和应答时间长度，最长不能超过多少个 tickTime 的时间长度，总的时间长度就是 2*2000=4 秒
server.A=B：C：D：其 中 A 是一个数字，表示这个是第几号服务器；B 是这个服务器的 ip  地址；C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口；D 表示的是万一  集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader，而这  个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式，由于 B 都是  一样，所以不同的 Zookeeper 实例通信端口号不能一样，所以要给它们分配不同的端口号

 

特点：

角色功能： 

领导者（leader）	负责进行投票的发起和决议，更新系统状态
学习者（learner）	包括跟随者（follower）和观察者（observer），follower用于接受客户端请求并向客户端返回结果，在选主过程中参与投票
Observer	可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度
客户端（client）	请求发起方

 集群特点：

特点	说明
最终一致性	为客户端展示同一个视图，这是zookeeper里面一  个非常重要的功能
可靠性	如果消息被一台服务器接受，那么它将被所有的服务器接受。
实时性	Zookeeper不能保证两个客户端能同时得到刚更新  的数据，如果需要最新数据，应该在读数据之前调  用sync()接口。
独立性	各个Client之间互不干预
原子性	更新只能成功或者失败，没有中间状态。
顺序性	所有Server，同一消息发布顺序一致。

 

常规搭建方式，进行操作：

A.关闭防火墙（测试环境）

systemctl stop firewalld.service 

B.启动 服务，每个规划的 zookeeper 节点都要进行启动

 zkServer.sh status

C.启动客户端

zkCli.sh 

D.命令使用

1. help

2. ls 查看当前存在的根目录

3. znode 节点

ls 显示的节点: 数据模型Znode, 不是file 文件

znode 数据模型： 层次的，目录型结构，包含最大1MB的数据信息，记录了Zxid等元数据信息

Znode有两种类型，短暂的（ephemeral）和持久的（persistent）

Znode的类型在创建时确定并且之后不能再修改

Znode有四种形式的目录节点

1. PERSISTENT   
2. EPHEMERAL   
3. PERSISTENT_SEQUENTIAL   
4. EPHEMERAL_SEQUENTIAL

4. create 创建节点

a. 创建临时节点，获得临时节点的数据

短暂znode的客户端会话结束时，zookeeper会将该短暂znode删除，短暂znode不可以有子节点

create -e /tmp xiaoming

get /tmp

查看节点的详细信息

get -s /tmp

b.创建持久化节点，获得临时节点的数据

创建序列节点（不指定 -e 参数，则表示是持久化节点）====》持久化的序列节点

 create -s /yang  yang

c.创建子节点

create /yang0000000049/zzu zzu

获得子节点的数据

get -s /yang0000000049/zzu

d.创建孙子节点

create /yang0000000049/zzu/abc abc

 

e.znode节点数据结构

get -s /tmp

znode数据模型的数据
xiaoming	节点数据
cZxid = 0x470000006b	创建的事务id（递增的形式）
ctime = Sat Oct 03 10:54:44 CST 2020	创建时间
mZxid = 0x470000006b	修改的事务id (递增的形式)
mtime = Sat Oct 03 10:54:44 CST 2020	修改时间
pZxid = 0x470000006b	最新创建的子节点的事务id
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x2001b8d03f80007	表示临时节点（持久化的节点的值为: 0x0)
dataLength = 8	节点数据的长度
numChildren = 0	直接的子节点的数量，不包含孙子节点

 

E.数据同步

原子广播，实现这个机制的协议叫做Zab协议。

Zab协议有两种模式： 恢复模式        广播模式。

恢复模式

当服务启动或者在领导者崩溃后 Zab就进入了恢复模式， 当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。

leader 选举

在无主的模型下首先进行的是自我投票，在选举过程中，如果发现对方的zxid 比自己的大，则选择对方为主，否则选择自己

广播模式

广播模式需要保证提议（proposal）被按顺序处理，因此zk采用了递增的事务id号(zxid)来保证。 所有的提议  (proposal)都在被提出的时候加上了zxid。 实现中zxid是一个64为的数字，它高32位是epoch用来标识  leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，低32位是个递增计数。

提议，比如说创建表的时候会产生，cZxid、mZxid、pZxid 同一个 Zxid 被成为是一个 提议

提议的概念是从 paxos （帕克西）算法来的。

按照从客户端发起请求1，到收到请求6  这个过程中， 比如说是创建一个节点

这个时候收到请求的节点会向主节点发送请求，

主机节点生成一个 提议（pronosal）广播到所有的从节点（follower）出去，

当超过半数的 从节点（follower）返回 ack（同意信息），则该条提议通过，

主节点向全部的节点（从节点（follower）和观察节点（observer）） 广播进行通知该 提议（pronosal）

之后当其他客户端访问任意一个从节点的时候，都能返回 刚才创建的节点的信息