前面Zookeeper(1)，我们介绍了下zookeeper和如何安装zookeeper集群，本篇文章我们主要详细介绍zookeeper的数据结构，突出特征（监听机制），选举原理等。
Zookeeper数据结构
数据结构Znode
特征
在ZooKeeper中，数据信息被保存在一个个数据节点上，这些节点被称为znode。
ZNode 是 Zookeeper 中最小数据单位，在 ZNode 下面又可以再挂 ZNode，这样一层层下去就形成了一个层次化 命名空间 ZNode 树，我们称为 ZNode Tree，它采用了类似文件系统的层级树状结构进行管理
ZNode
的节 点路径标识方式和Unix
文件系统路径非常相似，都是由一系列使用斜杠（
/
）进行分割的路径表示，开发人员可以向这个节点写入数据，也可以在这个节点下面创建子节点
ZNode 的类型分类
持久性节点（Persistent）
- 临时性节点（Ephemeral）
- 顺序性节点（Sequential）
在创建节点的时候通过组合可以生成以下四种节点类型：持久节点、持久顺序节点、临时节点、临时顺序节点。不同类型的节点则会有不同的生命周期
（1）持久节点：
是Zookeeper中最常见的一种节点类型，所谓持久节点，就是指节点被创建后会一直存在服务器，直到删除操作主动清除
（2）持久顺序节点：
是有顺序的持久节点，节点特性和持久节点是一样的，只是额外特性表现在顺序上。顺序特性实质是在创建节点的时候，会在节点名后面加上一个数字后缀，来表示其顺序。
（3）临时节点：
会被自动清理掉的节点，它的生命周期和客户端会话绑在一起，客户端会话结束，节点会被删除掉。与持久性节点不同的是，临时节点不能创建子节点。
（4）临时顺序节点：
是有顺序的临时节点，和持久顺序节点相同，在其创建的时候会在名字后面加上数字后缀。事务
数据库事务具有所谓的ACID特 性，即原子性（Atomic）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）
在ZooKeeper中，事务是指能够改变ZooKeeper服务器状态的操作，我们也称之为事务操作或更新操作。
一般包括数据节点创建与删除、数据节点内容更新等操作。对于每一个事务请求，ZooKeeper 都 会为其分配一个全局唯一的事务ID ，用 ZXID 来表示，通常是一个 64 位的数字。每一个 ZXID 对应一次更新操作，从这些ZXID 中可以间接地识别出 ZooKeeper 处理这些更新操作请求的全局顺序 。zk 对这些事务操作都 会编号，这个编号是自增长的被称为ZXID 。
#
使用
bin/zkCli.sh
连接到
zk
集群
cZxid 就是 Create ZXID，表示节点被创建时的事务ID。
ctime 就是 Create Time，表示节点创建时间。
mZxid 就是 Modified ZXID，表示节点最后一次被修改时的事务ID。
mtime 就是 Modified Time，表示节点最后一次被修改的时间。
pZxid 表示该节点的子节点列表最后一次被修改时的事务 ID。只有子节点列表变更才会更新 pZxid，子 节点内容变更不会更新。
cversion 表示子节点的版本号。
dataVersion 表示内容版本号。
aclVersion 标识acl版本
ephemeralOwner 表示创建该临时节点时的会话
sessionID，如果是持久性节点那么值为 0
dataLength 表示数据长度。
numChildren 表示直系子节点数。Watcher 机制
在 ZooKeeper 中，引入了 Watcher 机制来实现分布式的通知功能。 ZooKeeper 允许客户端向服 务端注册一个 Watcher 监听，当服务端的一些指定事件触发了这个 Watcher ，那么 Zk 就会向指定客户 端发送一个事件通知来实现分布式的通知功能。
Zookeeper 的 Watcher 机制主要包括 客户端线程、客户端 WatcherManager 、 Zookeeper 服务器 三部 分。具体工作流程为：
- 客户端在向Zookeeper服务器注册的同时，会将Watcher对象存储在客户端的WatcherManager当中
- 当Zookeeper服务器触发Watcher事件后，会向客户端发送通知
- 客户端线程从WatcherManager中取出对应的Watcher对象来执行回调逻辑
ZooKeeper命令行操作
首先，进入到 zookeeper 的 bin 目录之后 通过zkClient 进入 zookeeper 客户端命令行./zkcli.sh 连接本地的 zookeeper 服务器./zkCli.sh -server ip:port(2181) 连接指定的服务器
创建节点
创建顺序节点
create -s /zk-test 123
创建临时节点
create -e /zk-temp 123
创建永久节点
create /zk-permanent 123
读取节点
ls [path]命令可以列出Zookeeper指定节点下的第一级的所有子节点；
get [path] 命令可以获取Zookeeper指定节点的数据内容和属性信息。
更新节点
使用
set
命令，可以更新指定节点的数据内容
set path data
删除节点
delete path
若删除节点存在子节点，那么无法
删除该节点，必须先删除子节点，再删除父节点
Leader选举
选举机制
半数机制：集群中半数以上机器存活，集群可用。所以 Zookeeper 适合安装奇数台服务器。Zookeeper虽然在配置文件中并没有指定 Master 和 Slave 。但是， Zookeeper 工作时，是有一个节 点为Leader ，其它为 Follower ， Leader 是通过内部的选举机制产生的。
集群首次启动选举原理
Zookeeper的选举机制
（1）服务器1启动，此时只有它一台服务器启动了，它发出去的报文没有任何响应，所以它的选举状态
一直是LOOKING状态。
（2）服务器2启动，它与最开始启动的服务器1进行通信，互相交换自己的选举结果，由于两者都没有
历史数据，所以id值较大的服务器2胜出，但是由于没有达到超过半数以上的服务器都同意选举它(这个
例子中的半数以上是3)，所以服务器1、2还是继续保持LOOKING状态。
（3）服务器3启动，根据前面的理论分析，服务器3成为服务器1、2、3中的老大，而与上面不同的
是，此时有三台服务器选举了它，所以它成为了这次选举的Leader。
（4）服务器4启动，根据前面的分析，理论上服务器4应该是服务器1、2、3、4中最大的，但是由于前
面已经有半数以上的服务器选举了服务器3，所以它只能接收当小弟的命了。
（5）服务器5启动，同4一样称为follower。集群非首次启动选举原理
每个节点在选举时都会参考自身节点的
zxid
值（事务
ID
）；优先选择
zxid
值大的节点称为
Leader!!
集群的优点
- 将数据复制到分布式部署的多台机器中，可以消除单点故障，防止系统由于某台（些）机器宕机导 致的不可用。
- 通过负载均衡技术，能够让分布在不同地方的数据副本全都对外提供服务。有效提高系统性能。
集群的数据管理
为什么会出现分布式数据一致性问题?
当客户端Client1将系统中的一个值 K1 由 V1 更新为 V2 ，但是客户端 Client2 读取的是一个还没有同步更新 的副本，K1 的值依然是 V1, 这就导致了数据的不一致性。其中，常见的就是主从数据库之间的复制延时 问题。
ZK怎么处理集群中的数据？
所有客户端写入数据都是写入Leader中，然后，由 Leader 复制到Follower中。ZAB会将服务器数据的状态变更以事务Proposal的形式广播到所有的副本进程上，ZAB协议能够保证了事务操作的一个全局的变更序(ZXID)。
ZAB一致性协议
ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持崩溃恢复和原子广播协议。ZAB 协议的消息广播过程类似于 二阶段提交过程 。对于客户端发送的 写请求 ，全部由 Leader 接收， Leader 将请求封装成一个事务 Proposal( 提议 ) ，将其发送给所有 Follwer ，如果收到超过半数反馈 ACK，则执行 Commit 操作（先提交自己，再发送 Commit 给所有 Follwer ），如果没有接受到其中一台follwer的commit 提交成功信号+leader的commit提交成功信号，它也就不会返回给客户端成功信息。
Leader
崩溃问题
Leader 宕机后， ZK 集群无法正常工作， ZAB 协议提供了一个高效且可靠的 leader 选举算法。这个选举算法的关键点：保证选举出的新Leader拥有集群中所有节点最大编号(ZXID)的事务!!Leader 宕机后，被选举的新 Leader 需要解决的问题
- ZAB 协议确保那些已经在 Leader 提交的事务最终会被所有服务器提交。
- ZAB 协议确保丢弃那些只在 Leader 提出/复制，但没有提交的事务。
基于上面的目的， ZAB 协议设计了一个选举算法：能够确保已经被 Leader 提交的事务被集群接受，丢弃还没有提交的事务。
注：以上为本人小小总结，如果对您起到了一点点帮助，请给予我一点鼓励，在下方点个小小的赞，谢谢，如有错误之处，望不吝指出，非常感谢！
扫一扫
5909
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
