关于zookeeper:一文了解Zookeeper

5次阅读

共计 2711 个字符,预计需要花费 7 分钟才能阅读完成。

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 准时推送技术文章,让你的下班路不在孤单,而且每月还有送书流动,助你晋升硬实力!

正文完
 0