zookeeper 基础(2)

84 阅读 0 评论 56 点赞

我是靠谱客的博主复杂老虎，最近开发中收集的这篇文章主要介绍zookeeper 基础(2)，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

Zookeeper会话机制

Session会话

官网地址：https://zookeeper.apache.org/doc/current/zookeeperOver.html

Ø一个客户端连接一个会话，由zk分配唯一会话id；

Ø 客户端以特定的时间间隔发送心跳以保持会话有效； tickTime

Ø 超过会话超时时间未收到客户端的心跳，则判定客户端死了；(默认2倍tickTime)

Ø 会话中的请求按FIFO顺序执行。

znode—数据构成

数据构成

Ø 节点数据：存储协调数据（状态信息，配置，位置信息等）

Ø 节点元数据（stat结构，其中包括数据更改，ACL更改和时间戳的版本号，以允许缓存验证和协调更新。每次znode的数据更改时，版本号都会增加）

Ø 数据大小上限：1M

znode—节点类型

持久节点

临时节点

顺序节点

Ø10位十进制序号

Ø每个父节点一个计数器

Ø计数器是带符号的int(4字节)到2147483647之后将溢出(导致名称“<path>-2147483648”)

临时顺序节点

持久节点 - 即使在创建该特定znode的客户端断开连接后，持久节点仍然存在。默认情况下，除非另有说明，否则所有znode都是持久的。

临时节点 - 客户端活跃时，临时节点就是有效的。当客户端与ZooKeeper集合断开连接时，临时节点会自动删除。因此，只有临时节点不允许有子节点。如果临时节点被删除，则下一个合适的节点将填充其位置。临时节点在leader选举中起着重要作用。

顺序节点 - 顺序节点可以是持久的或临时的。当一个新的znode被创建为一个顺序节点时，ZooKeeper通过将10位的序列号附加到原始名称来设置znode的路径。例如，如果将具有路径 /myapp 的znode创建为顺序节点，则ZooKeeper会将路径更改为 /myapp0000000001 ，并将下一个序列号设置为0000000002。如果两个顺序节点是同时创建的，那么ZooKeeper不会对每个znode使用相同的数字。顺序节点在锁定和同步中起重要作用。这个计数器对于父znode是惟一的。计数器的格式为%010d——即填充为0(0)的10位数字(计数器采用这种格式是为了简化排序)，即“<路径> 0000000001”。注意:用于存储下一个序列号的计数器是由父节点维护的带符号int(4字节)，当增加到2147483647之后计数器将溢出(导致名称“<path>-2147483648”)。

Watch监听机制

客户端可以在znodes上设置watch ，监听znode的变化。

两类watch

data watch 节点监听

child watch 子节点监听

触发watch

Created event:

Enabled with a call to exists.

Deleted event:

Enabled with a call to exists, getData, and getChildren.

Changed event:

Enabled with a call to exists and getData.

Child event:

Enabled with a call to getChildren.

watch重要性

Ø一次性触发：watch触发后即被删除。要持续监控变化，则需要持续设置watch。

Ø 有序性：客户端先得到watch通知，后才会看到变化结果。

watch注意事项

1. watch是一次性触发器;如果您获得了一个watch事件，并且希望得到关于未来更改的通知，则必须设置另一个watch。

2.因为watch是一次性触发器，并且在获取事件和发送获取watch的新请求之间存在延迟，所以不能可靠地得到节点发生的每个更改。

3.一个watch对象只会被特定的通知触发一次。如果一个watch对象同时注册了exists、getData，当节点被删除时，删除事件对exists 、getData都有效，但只会调用watch一次。

Zookeeper特性：

官方文档

Guarantees

ZooKeeper is very fast and very simple. Since its goal, though, is to be a basis for the construction of more complicated services, such as synchronization, it provides a set of guarantees. These are:

Sequential Consistency - Updates from a client will be applied in the order that they were sent.
Atomicity - Updates either succeed or fail. No partial results.
Single System Image - A client will see the same view of the service regardless of the server that it connects to.
Reliability - Once an update has been applied, it will persist from that time forward until a client overwrites the update.
Timeliness - The clients view of the system is guaranteed to be up-to-date within a certain time bound.