乐趣区

关于zookeeper:一文了解Zookeeper

jiezi

Zookeeper 是 Apache 开源的一个分布式框架，它次要为分布式应用提供协调服务。

Zookeeper 次要负责存储和治理大家都关怀的数据，一旦这些数据的状态发生变化，Zookeeper 就会告诉那些注册在 Zookeeper 上的服务。简略来讲就是 zookeeper= 文件系统 + 告诉机制。

一 Zookeeper 的数据结构

Zookeeper 的数据结构与 Unix 文件系统很相似，整体上能够看作是一棵树，与 Unix 文件系统不同的是 Zookeeper 的每个节点都能够存放数据，每个节点称作一个 ZNode，默认存储 1MB 的数据，每个 ZNode 都能够通过其门路惟一标识。

1.1 四种类型的 ZNode

  • 长久化目录节点：客户端与 Zookeeper 断开连接后，该节点仍旧存在。
  • 长久化程序编号目录节点：客户端与 Zookeeper 断开连接后，该节点仍旧存在，只是 Zookeeper 给该节点名称就行程序编号。
  • 长期目录节点：客户端与 Zookeeper 断开连接后，该节点被删除。
  • 长期程序编号目录节点：客户端与 Zookeeper 断开连接后，该节点被删除，只是 Zookeeper 给该节点名称就行程序编号。

阐明：创立 ZNode 时设置程序标识，ZNode 名称后会附加一个值，顺序号是一个枯燥递增的计数器，由父节点保护。

1.2 stat 构造体

ZNode 次要蕴含以下信息：

  • czxid- 创立节点的事务 zxid：

每次批改 ZooKeeper 状态都会收到一个 zxid 模式的工夫戳，也就是 ZooKeeper 事务 ID。

事务 ID 是 ZooKeeper 中所有批改总的秩序。每个批改都有惟一的 zxid，如果 zxid1 小于 zxid2，那么 zxid1 在 zxid2 之前产生。

  • ctime：znode 被创立的毫秒数(从 1970 年开始)
  • mzxid：znode 最初更新的事务 zxid
  • mtime：znode 最初批改的毫秒数(从 1970 年开始)
  • pZxid：znode 最初更新的子节点 zxid
  • cversion：znode 子节点变动号，znode 子节点批改次数
  • dataversion：znode 数据变动号
  • aclVersion：znode 访问控制列表的变动号
  • ephemeralOwner：如果是长期节点，这个是 znode 拥有者的 session id。如果不是长期节

点则是 0

  • dataLength：znode 的数据长度
  • numChildren：znode 子节点数量

二 Zookeeper 的利用场景

Zookeeper 的次要利用场景有对立命名服务，对立配置管理，对立集群治理，服务器节点动静高低线等。

2.1 对立命名服务

在分布式环境中，常常须要对服务进行对立命名，如果有一个服务部署了 2 两个正本，间接调用具体的服务必定有些不适合，因为咱们并不分明哪个服务能够更快的解决咱们的申请，这时候咱们能够将这三个服务进行对立命名，而后其外部再去负载。这样就能够调用最优的那个服务了。

2.2 对立配置管理

分布式环境下，配置文件的同步能够由 Zookeeper 来实现。

  1. 将配置文件写入 Zookeeper 的一个 ZNode
  2. 各个客户端服务监听这个 ZNode
  3. 一旦 ZNode 产生扭转，Zookeeper 将告诉各个客户端服务

2.3 对立集群治理

Zookeeper 能够实现实时监控节点状态变动，当有一个三个节点的服务，如果其余一个宕机了，其余两个节点可立刻收到音讯，实现实时监控。将这三个节点写入 Zookeeper 的一个 ZNode，每个节点都去监听这个 ZNode，当 ZNode 发生变化时，这些节点可实时收到变动状态。

监听器的原理

  1. 创立一个 Main()线程
  2. 在 Main()线程中创立两个线程，一个负责网络连接通信（connect），一个负责监听（listener）
  3. 通过 connect 线程将注册的监听事件发送给 Zookeeper
  4. 将注册的监听事件增加到 Zookeeper 的注册监听器列表中
  5. Zookeeper 监听到有数据或门路发生变化时，把这条音讯发送给 Listener 线程
  6. Listener 线程外部调用 process()办法

三 Zookeeper 集群

Zookeeper 集群尽管没有指定 Master 和 Slave。然而，在 Zookeeper 工作时，会通过外部选举机制产生一个 Leader 节点，其余节点为 Follower 或者是 Observer。

被申明为 Observer 的节点，不参加选举过程，也不参加写操作的”过半写胜利“策略。

过半写胜利策略：Leader 节点接管到写申请后，这个 Leader 会将写申请播送给各个 server，各个 server 会将该写申请退出待写队列，并向 Leader 发送胜利信息，当 Leader 收到一半以上的胜利音讯后，阐明该写操作能够执行。Leader 会向各个 server 发送提交音讯，各个 server 收到音讯后开始写。

Follower 和 Observer 只提供数据的读操作，当他们接管的写申请时，会将该申请转发给 Leader 节点。

集群中只有有半数以上的节点存活，Zookeeper 集群就能失常服务。因而 Zookeeper 集群适宜装置奇数台机器。

3.1 选举机制

（1）服务器 1 启动，发动一次选举。服务器 1 投本人一票。此时服务器 1 票数一票，不够半数以上（3 票），选举无奈实现，服务器 1 状态放弃为 LOOKING；

（2）服务器 2 启动，再发动一次选举。服务器 1 和 2 别离投本人一票并替换选票信息：此时服务器 1 发现服务器 2 的 ID 比本人目前投票推举的（服务器 1）大，更改选票为推举服务器 2。此时服务器 1 票数 0 票，服务器 2 票数 2 票，没有半数以上后果，选举无奈实现，服务器 1，2 状态放弃 LOOKING；

（3）服务器 3 启动，发动一次选举。此时服务器 1 和 2 都会更改选票为服务器 3。此次投票后果：服务器 1 为 0 票，服务器 2 为 0 票，服务器 3 为 3 票。此时服务器 3 的票数曾经超过半数，服务器 3 入选 Leader。服务器 1，2 更改状态为 FOLLOWING，服务器 3 更改状态为 LEADING；

（4）服务器 4 启动，发动一次选举。此时服务器 1，2，3 曾经不是 LOOKING 状态，不会更改选票信息。替换选票信息后果：服务器 3 为 3 票，服务器 4 为 1 票。此时服务器 4 遵从少数，更改选票信息为服务器 3，并更改状态为 FOLLOWING；

（5）服务器 5 启动，同 4 一样当小弟。

点关注、不迷路

如果感觉文章不错，欢送 关注 、 点赞 、 珍藏，你们的反对是我创作的能源，感激大家。

如果文章写的有问题，请不要悭吝，欢送留言指出，我会及时核查批改。

如果你还想更加深刻的理解我，能够微信搜寻「Java 旅途」进行关注。回复「1024」即可取得学习视频及精美电子书。每天 7:30 准时推送技术文章，让你的下班路不在孤单，而且每月还有送书流动，助你晋升硬实力！

退出移动版