这是我参与11月更文挑战的第3天，活动详情查看：2021最后一次更文挑战
前言
通过前面两个章节的学习，相信小伙伴们对Zookeeper有了一个初步的认识，今天就和大家一起学习Zookeeper的核心部分，比如我们能够创建的节点类型有哪些？znode中的参数都表示什么？监听机制是什么？zk有哪些特性？
这一系列的问题在今天的文章中，花哥都会逐个讲解，还没有学习前两章内容的小伙伴，点击下面这个直通车可以学习一下哦。
会话（session）
我们先来看下面这个Zookeeper的系统架构图，可以看到服务器（Server）可以接受多个客户端（Client）的连接，而每一个客户端连接到服务器，就会生成一个会话，zk会生成一个唯一会话id。
有一点需要注意，leader是不允许客户端连接的，除非leaderServes 参数被显示设置。
为了保持客户端与服务器的会话有效，客户端会以特定的时间频率发送心跳，如果服务器超过会话超时时长（默认为2倍tickTime）还没有收到客户端的心跳，就会将该服务器判断为挂了。
- 客户端连接时生成的会话id
客户端会维护一个TCP连接，后续通过这个连接能够发送请求，接收服务器响应、获取监听事件等。
Znode节点类型
前面文章我们学到，Zookeeper是由一个个节点（Znode）组成，而Znode又包含多种类型，下面花哥一一列出。
| 节点类型 | 举例 | 描述 |
|---|---|---|
| 持久节点 | create /testData 100 | 一旦创建，就会持久化 |
| 顺序节点 | ①：create -s /testData/name huage ②：create -s /testData/ name | zk会在路径后追加10位的数字，如name40000000007,数字由1开始，逐步递增，最大值为2^32-1 |
| 临时节点 | create -e /testData 100 | 客户端断开后，会被删除 |
| 临时顺序节点 | create -e -s /testData/age 18 | 临时节点+顺序节点的组合 |
每个节点最多可以存放1M的数据。
Znode数据构成
知道了有几种节点类型，接下来我们就来看看每一个节点的组成。
每一个Znode由四个部分组成：存储数据（data）、访问权限（acl）、子节点引用（children）、状态信息（stat）
| 名称 | 描述 |
|---|---|
| data | 存储的业务数据 |
| acl | 客户端对Znode的访问权限 |
| children | 当前节点的子节点引用 |
| stat | 包含Znode节点的状态信息，如事务id、版本号等 |
上面四种较为复杂的是节点元数据（stat），先通过get命令查看节点信息，可以看到除了该节点的值以外，还包含了很多其他参数。
上面这些参数就是元数据，下面直接贴出表格，大家务必要一一了解。
| 名称 | 描述 |
|---|---|
| cZxid | 创建该节点的事务id |
| mZxid | 最后修改该节点的事务id |
| pZxid | znode最后更新的子节点事务id |
| ctime | 该节点创建时间 |
| mtime | 该节点最后修改时间 |
| cversion | 该节点的子节点版本号，初始值为-1，每次子节点修改，该值会自动增加 |
| dataVersion | 该节点被修改的次数，初始版本为0，每对该节点的数据进行操作，都会自动增加 |
| aclVersion | 当前节点的acl权限版本号 |
| ephemeraOwner | 临时节点的拥有者会话id，如果不是临时节点，默认为0 |
| dataLength | 该节点数据长度 |
| numChildren | 子节点数 |
如果觉得看表格太恶心…….，花哥贴心的演示一波。
首先新建一个节点，使用get查看节点的数据。
我们直接打开另一个客户端，将这个节点修改一下，是不是发现最后修改的事务id（mZxid）、最后修改时间（mtime）、修改次数（dataVersion）都已经发生了变化。
如果对子节点操作的话，会有什么变化呢，一个小问题希望小伙伴么自己动手试一下。
watch监听机制
昨天的文章中，我们也用实例演示了watch的用法，今天拿出来再重点讲解一下。
下面这个是通过【get -w 节点路径】来监听该节点，只要该节点被修改，在监听端的客户端就会收到消息通知。
同样也可以使用ls -w来监听节点的新增或删除变化。
在命令行我们可以通过上面这种方式来监听节点，那在java中我们也可以用getData() 、getChildren() 、exists() 来实现监听事件。
Watch有以下两个特性：
- 一次性触发：watch在触发之后，就会被删除，如果想要持续收到消息通知，就需要持续设置watch；
- 有序性：客户端先收到watch通知，然后才会查看到节点的变化。
有一点需要提出，由于watch是一次性触发，在接收到一次变更通知后，当再次发起watch请求时，会有一定延迟，如果此时节点再次变化，那就会丢失这次的变更。
ZooKeeper的特性
最后，我们来看一下ZooKeeper有哪些特性呢
- 顺序一致性：Leader服务器会根据请求顺序生成事务id，保证客户端操作是按顺序生效的；
- 原子性：所有事务请求的处理结果要么成功、要么失败，没有部分结果；
- 单一系统映像：无论客户端连到哪一个服务器，看到的数据都是一致的；
- 可靠性：数据一旦变更就不会丢失；
- 实时性：保证客户端当时读取的数据是最新的。
写到最后
今天讲了不少内容，是时候展现真的技术了，明天我们就可以看一下Zookeeper的实际应用场景，了解学这个玩意到底有什么用，用在哪里。文中如果有哪些错误，希望小伙伴们指出，共同学习哦。
本文转载自: 掘金