《我想进大厂》之Zookeeper夺命连环9问(一)

发布于 2022-6-9 16:42
浏览
0收藏

 

谈谈你对Zookeeper的理解?

Zookeeper是一个开源的分布式协调服务,由雅虎公司创建,由于最初雅虎公司的内部研究小组的项目大多以动物的名字命名,所以后来就以Zookeeper(动物管理员)来命名了,而就是由Zookeeper来负责这些分布式组件环境的协调工作。

他的目标是可以提供高性能、高可用和顺序访问控制的能力,同时也是为了解决分布式环境下数据一致性的问题。

集群

首先,Zookeeper集群中有几个关键的概念,Leader、Follower和Observer,Zookeeper中通常只有Leader节点可以写入,Follower和Observer都只是负责读,但是Follower会参与节点的选举和过半写成功,Observer则不会,他只是单纯的提供读取数据的功能。

通常这样设置的话,是为了避免太多的从节点参与过半写的过程,导致影响性能,这样Zookeeper只要使用一个几台机器的小集群就可以实现高性能了,如果要横向扩展的话,只需要增加Observer节点即可。

Zookeeper建议集群节点个数为奇数,只要超过一半的机器能够正常提供服务,那么整个集群都是可用的状态。

 《我想进大厂》之Zookeeper夺命连环9问(一)-开源基础软件社区
数据节点Znode

Zookeeper中数据存储于内存之中,这个数据节点就叫做Znode,他是一个树形结构,比如/a/b/c类似。

而Znode又分为持久节点、临时节点、顺序节点三大类。

持久节点是指只要被创建,除非主动移除,否则都应该一直保存在Zookeeper中。

临时节点不同的是,他的生命周期和客户端Session会话一样,会话失效,那么临时节点就会被移除。

还有就是临时顺序节点和持久顺序节点,除了基本的特性之外,子节点的名称还具有有序性。

会话Session

会话自然就是指Zookeeper客户端和服务端之间的通信,他们使用TCP长连接的方式保持通信,通常,肯定会有心跳检测的机制,同时他可以接受来自服务器的Watch事件通知。

事件监听器Wather

用户可以在指定的节点上注册Wather,这样在事件触发的时候,客户端就会收到来自服务端的通知。

权限控制ACL

Zookeeper使用ACL来进行权限的控制,包含以下5种:

  1. CREATE,创建子节点权限
  2. DELETE,删除子节点权限
  3. READ,获取节点数据和子节点列表权限
  4. WRITE,更新节点权限
  5. ADMIN,设置节点ACL权限
    所以,Zookeeper通过集群的方式来做到高可用,通过内存数据节点Znode来达到高性能,但是存储的数据量不能太大,通常适用于读多写少的场景。

Zookeeper有哪些应用场景?

  1. 命名服务Name Service,依赖Zookeeper可以生成全局唯一的节点ID,来对分布式系统中的资源进行管理。
  2. 分布式协调,这是Zookeeper的核心使用了。利用Wather的监听机制,一个系统的某个节点状态发生改变,另外系统可以得到通知。
  3. 集群管理,分布式集群中状态的监控和管理,使用Zookeeper来存储。
  4. Master选举,利用Zookeeper节点的全局唯一性,同时只有一个客户端能够创建成功的特点,可以作为Master选举使用,创建成功的则作为Master。
  5. 分布式锁,利用Zookeeper创建临时顺序节点的特性。

说说Wather监听机制和它的原理?

Zookeeper可以提供分布式数据的发布/订阅功能,依赖的就是Wather监听机制。

客户端可以向服务端注册Wather监听,服务端的指定事件触发之后,就会向客户端发送一个事件通知。

他有几个特性:

  1. 一次性:一旦一个Wather触发之后,Zookeeper就会将它从存储中移除
  2. 客户端串行:客户端的Wather回调处理是串行同步的过程,不要因为一个Wather的逻辑阻塞整个客户端
  3. 轻量:Wather通知的单位是WathedEvent,只包含通知状态、事件类型和节点路径,不包含具体的事件内容,具体的时间内容需要客户端主动去重新获取数据

主要流程如下:

  1. 客户端向服务端注册Wather监听
  2. 保存Wather对象到客户端本地的WatherManager中
  3. 服务端Wather事件触发后,客户端收到服务端通知,从WatherManager中取出对应Wather对象执行回调逻辑
     《我想进大厂》之Zookeeper夺命连环9问(一)-开源基础软件社区

Zookeeper是如何保证数据一致性的?

Zookeeper通过ZAB原子广播协议来实现数据的最终顺序一致性,他是一个类似2PC两阶段提交的过程。

由于Zookeeper只有Leader节点可以写入数据,如果是其他节点收到写入数据的请求,则会将之转发给Leader节点。

主要流程如下:

  1. Leader收到请求之后,将它转换为一个proposal提议,并且为每个提议分配一个全局唯一递增的事务ID:zxid,然后把提议放入到一个FIFO的队列中,按照FIFO的策略发送给所有的Follower
  2. Follower收到提议之后,以事务日志的形式写入到本地磁盘中,写入成功后返回ACK给Leader
  3. Leader在收到超过半数的Follower的ACK之后,即可认为数据写入成功,就会发送commit命令给Follower告诉他们可以提交proposal了
     《我想进大厂》之Zookeeper夺命连环9问(一)-开源基础软件社区
    ZAB包含两种基本模式,崩溃恢复和消息广播。

整个集群服务在启动、网络中断或者重启等异常情况的时候,首先会进入到崩溃恢复状态,此时会通过选举产生Leader节点,当集群过半的节点都和Leader状态同步之后,ZAB就会退出恢复模式。之后,就会进入消息广播的模式。

那么,Zookeeper如何进行Leader选举的?

Leader的选举可以分为两个方面,同时选举主要包含事务zxid和myid,节点主要包含LEADING\FOLLOWING\LOOKING3个状态。

  1. 服务启动期间的选举
  2. 服务运行期间的选举

服务启动期间的选举

  1. 首先,每个节点都会对自己进行投票,然后把投票信息广播给集群中的其他节点
  2. 节点接收到其他节点的投票信息,然后和自己的投票进行比较,首先zxid较大的优先,如果zxid相同那么则会去选择myid更大者,此时大家都是LOOKING的状态
  3. 投票完成之后,开始统计投票信息,如果集群中过半的机器都选择了某个节点机器作为leader,那么选举结束
  4. 最后,更新各个节点的状态,leader改为LEADING状态,follower改为FOLLOWING状态

服务运行期间的选举

如果开始选举出来的leader节点宕机了,那么运行期间就会重新进行leader的选举。

  1. leader宕机之后,非observer节点都会把自己的状态修改为LOOKING状态,然后重新进入选举流程
  2. 生成投票信息(myid,zxid),同样,第一轮的投票大家都会把票投给自己,然后把投票信息广播出去
  3. 接下来的流程和上面的选举是一样的,都会优先以zxid,然后选择myid,最后统计投票信息,修改节点状态,选举结束

 

文章转自公众号:艾小仙

分类
标签
已于2022-6-9 16:42:11修改
收藏
回复
举报
回复
添加资源
添加资源将有机会获得更多曝光,你也可以直接关联已上传资源 去关联
    相关推荐