Zookeeper(三) 原理

Zookeeper的事件通知

可以把Watch理解成注册在Znode上的触发器, 当这个Znode发生改变, 也就是调用了create, delete, setData方法的时候, 将会触发Znode上注册的对应事件, 请求Watch的客户会收到异步通知

具体交互过程如下:

客户端使用getData方法, watch参数是true, 服务端接收到请求, 返回节点数据, 并且在对应的哈希表里插入被watch的Znode路径, 以及Watcher里列表

具体交互过程如下:

客户端调用getData方法, watch参数是true, 服务端接到请求, 返回节点数据, 并且在对应的哈希表里插入被watch的Znode路径, 以及Watcher列表

当Watch的Znode已删除, 找到该Znode对应的所有Watcher, 异步通知客户端, 并且删除哈希表中对应的Key-value.

服务上线后, 服务A, B, C需要注册到Zookeeper服务器, 把服务的IP地址写到zookeeper

API网关也要注册到Zookeeper

服务A将访问路径和ip地址写到了zookeeper, 并形成了映射, 当API网关在访问/user/reg路径的时候, 就从zookeeper中获得了服务A的ip地址, 并在访问/user/reg进行了watch

为什么要观察呢? 因为会出现副本, 副本同理要注册到zookeeper

当API网关防卫/user/reg服务后, 192.168.0.1和/user/reg的映射就通过zkClient维护在API网关的列表里, 下次再访问的时候就可以在API网关处直接返回

如果192.168.0.1的服务下线了, 这时zookeeper通过一个异步通知到zkClient, zkClient在维护的网关列表里删除192.168.0.1的服务

这时用户再来访问/user/reg时候, 由zookeeper做到服务发现, 所以是高可用的用户服务, 0.1取不到了, 但是还可以取到0.4

所有的服务都要经过zookeeper进行服务注册与发现, 如果zookeeper宕机了, 就都不用玩了, 所以zookeeper服务注册与发现服务器必须实现高可用, 如何实现zookeeper的高可用呢?

Zookeeper的一致性

Zookeeper身为分布式系统协调服务, 如果自身挂了如何处理呢? 为了防止单机挂掉的情况, Zookeeper维护了一个集群。如下图

Zookeeper Service集群是一主多从结构

在更新数据时, 首先更新到主节点(这里的节点是指服务器, 不是Znode), 再同步到从节点

在读取数据时, 直接读取任意从节点

为了保证主从节点的数据一致性, Zookeeper采用了ZAB协议, 这种协议非常类似于一致性算法Paxos和Raft。

什么是ZAB

Zookeeper Atomic Broadcast, 有效解决了Zookeeper集群奔溃恢复, 以及主从同步数据的问题。

ZAB协议定义的三种节点状态

looking: 选举状态

Following: Follower节点(从节点)所处的状态)

最大ZXID

最大ZXID也就是节点本地的最新事务编号, 包括epoch和计数两部分。epoch是纪元的意思, 相当于Raft算法选主时候的term

ZAB的崩溃恢复

假如Zookeeper当前的主节点挂掉了, 集群会进行奔溃恢复。ZAB的奔溃恢复分成三个阶段

Leader election

选举阶段, 此时集群中的节点处于Looking状态。它们会各自向其他节点发起投票, 投票中包含自己的服务器ID和最新事务ID(ZXID)

接下来, 节点会用自身的ZXID和从其他节点接收到的ZXID做比较, 如果发现别人家的ZXID比自己大, 也就是数据比自己新, 那么久重新发起投票, 投票给目前已知最大的ZXID所属节点

每次投票后, 服务器都会统计投票数据, 判断是否有某个节点得到半数以上的投票。如果存在这样的节点, 该节点将会成为准Leader, 状态变为leading。其他节点的状态变为Following。