ZooKeeper 特性记录

Watcher 通知次数

Watcher 只会通知一次,并且没有重试机制以及事务回滚。
意味着Watcher 只关心“通知"这个动作,而不关心客户端是否处理成功。
如果想继续获取事件通知,例如节点变更通知
那么在getData 时需要将watch 参数设置为true

Zookeeper 中心化架构

同一时刻只有一个节点可以处理写操作,就是Leader。
所以在ZooKeeper集群里,总有一个Leader被选举。

ZooKeeper 节点类型

Leader - 被选举出来的节点,主要处理写操作,及同步数据到各个子Follower节点
Follower - 子节点,主要提供读操作,并在Leader挂掉时参与选举(Election)
Observer - 观察者节点, 除了不能参与选举以外,跟Follower功能一样,
??主要用于扩展节点时(新增节点时会重新选举,需要使用一段时间),提供不间断的读操作??。

ZooKeeper 数据节点类型

分 持久化ZNode 和 临时ZNode 两大类
每个类型的ZNode 又分顺序ZNode 和 非顺序ZNode
即系以下四种:
a. 持久化ZNode
b. 持久化顺序ZNode
c. 临时ZNode
d. 临时顺序ZNode

临时节点会在session会话断开时销毁

zoo.cfg配置

  1. tickTime (默认:2000毫秒)
    表示 一个时间单位,即系后续其他配置项所配置的时间的基数。

  2. initLimit(默认:10)
    表示一个节点重新加入到群集后,同步数据所花的时间,
    该时间的值的计算为initLimit * tickTime, 例如 10*2000 = 20000;

  3. syncLimit(默认:5)
    表示节点之间的心跳时间,
    该时间的值的计算为 syncLimit * tickTime,例如 5 * 2000=10000;

新增ZooKeeper节点(不是数据ZNode)后的操作

  1. 同步数据
    如果数据同步失败,则该节点加入群集失败,不会标记成正常节点。
    同步数据所需要的时间为zoo.cfg配置里的 initLimit * tickTime。

  2. 重新选举??(还没确认这个事实)
    重新参与选举。

写入数据特性

当发起写入数据操作时,Leader会将数据同步到一半以上的节点之后就返回操作结果。

乐观锁性质

ZooKeeper的ZNode节点数据都包含一个dataVersion,这个dataVersion 可以在执行setData时指定一个修改前获取的dataVersion作为version参数,来尝试是否设置成功,跟数据乐观锁的概念是一样的。

Zookeeper 四字命令

通过TCP发送四个字母的命令到Zookeeper端口可以查看一些相关信息。
发送TCP包命令如下:

echo 'conf' | nc localhost 2181

conf
输出相关服务配置的详细信息。

cons
列出所有连接到服务器的客户端的完全的连接 /会话的详细信息。包括“接受 / 发送”的包数量、会话 id 、操作延迟、最后的操作执行等等信息。

dump
列出未经处理的会话和临时节点。

envi
输出关于服务环境的详细信息(区别于 conf命令)。

reqs

列出未经处理的请求

ruok
测试服务是否处于正确状态。如果确实如此,那么服务返回“imok ”,否则不做任何相应。

stat
输出关于性能和连接的客户端的列表。

wchs
列出服务器 watch的详细信息。

wchc
通过 session列出服务器 watch的详细信息,它的输出是一个与watch相关的会话的列表。

wchp
通过路径列出服务器 watch的详细信息。它输出一个与 session相关的路径。

你可能感兴趣的:(ZooKeeper 特性记录)