0
点赞
收藏
分享

微信扫一扫

面试总结——zookeeper

RJ_Hwang 2022-03-31 阅读 65
面试java

1. ZooKeeper 是什么?

  1. 开源的分布式协调服务

2. Zookeeper 怎么保证主从节点的状态同步?

  1. 原子广播机制,这个机制保证了各个 server 之间的同步
  2. 当服务启动或者在领导者崩溃后,Zab就进入了恢复模式,当领导者被选举出来,且大多数 server 完成了和 leader 的状态同步以后,恢复模式就结束了。
  3. 一旦 leader 已经和多数的 follower 进行了状态同步后,它就可以开始广播消息了,即进入广播状态。这时候当一个 server 加入 ZooKeeper 服务中,它会在恢复模式下启动,发现 leader,并和 leader 进行状态同步。待到同步结束,它也参与消息广播

3. Zookeeper Watcher 机制

  1. Zookeeper 允许客户端向服务端的某个 Znode 注册一个 Watcher 监听
  2. 服务端的一些指定事件触发了这个 Watcher,服务端会向指定客户端发送一个事件通知来实现分布式的通知功能,然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变。

4. Zookeeper内部的数据模型

  1. zk中的数据是保存在节点上的,节点就是znode,多个znode之间构成一棵树的目录结构
  2. 树是由节点构成,Zookeeper的数据存储也是基于节点,这种节点叫做Znode
  3. 但是不同于树的节点,Znode的引用方式是路径引用,类似于文件路径

5. zk中的znode是什么样的结构

包含四个部分

  1. data:保存数据
  2. acl:权限,定义了什么样的用户能够操作这个节点,且能够进行怎样的操作
  3. stat:描述当前znode的元数据
  4. child:当前节点的子节点

6. zk中节点znode的类型

  1. 持久节点:创建出的节点,在会话结束后依然存在。保存数据
  2. 持久序号节点: 创建出的节点,根据先后顺序,会在节点之后带上一个数值,越后执行数值越大,适用于分布式锁的应用场景- 单调递增
    create -s /mynode abc
  3. 临时节点:在会话结束后,自动被删除的,通过这个特性,zk可以实现服务注册与发现的效果
    create -e /mynode abc
  4. 临时序号节点:跟持久序号节点相同,适用于临时的分布式锁
    create -s -e /node1
  5. 容器Container节点:Container容器节点,当容器中没有任何子节点,该容器节点会被zk定期删除(60s)
  6. TTL节点:可以指定节点的到期时间,到期后被zk定时删除。只能通过系统配置 zookeeper.extendedTypesEnabled=true开启

7. zk的数据持久化

  1. 事务日志:把执行的命令以日志形式保存在dataLogDir指定的路径中的文件中
  2. 数据快照:在一定的时间间隔内做一次内存数据的快照

8. zk中锁的种类:

  1. 读锁(谈恋爱):大家都可以读,要想上读锁的前提是:之前没有写锁
  2. 写锁(结婚):只有得到写锁的才能写,要想上写锁的前提是:之前没有任何锁

9. zk如何上读锁

  1. 创建一个临时序号节点,节点的数据是read,表示读锁
  2. 获取当前zk中序号比自己小的节点
  3. 判断最小节点是不是读锁:
    1. 如果不是读锁的话,则上锁失败,为最小的节点设置监听。阻塞等待,zk的watch机制会当最小的节点发生变化时通知当前节点,于是执行第二步流程
    2. 如果是读锁的话,则上锁成功

10. zk如何上写锁

  1. 创建一个临时序号节点,节点的数据是write,表示写锁
  2. 获取zk中所有的子节点
  3. 判断自己是否是最小的节点
    1. 如果,则上锁成功
    2. 如果不是,说明前面还有锁,则上锁失败,监听最小的节点,如果最小的节点有变化,则回到第二步

11. 羊群效应

用上述上锁方式,只要节点发生变化,就会触发其他节点监听事件,这样的话对zk的压力非常大–>羊群效应,可以调整成链式监听来解决这个问题

12. 什么是ZBA协议?

zookeeper为了保证数据的一致性,使用了ZAB,这个协议解决了Zookeeper的崩溃恢复和主从数据同步的问题。

13. ZAB协议定义的四种节点状态

Looking :选举状态。
Following :Follower 节点(从节点)所处的状态。
Leading :Leader 节点(主节点)所处状态。
Observing:观察者节点所处的状态

14. CAP理论

CAP 理论为:一个分布式系统最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)这三项中的两项。

  1. 一致性,更新操作成功并返回客户端完成后,所有节点在同一时间的数据完全一致
  2. 可用性即服务一直可用,而且是正常响应时间。
  3. 分区容错性,即分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性或可用性的服务。——避免单点故障,就要进行冗余部署,冗余部署相当于是服务的分区,这样的分区就具备了容错性。
举报

相关推荐

0 条评论