zookeeper 面试题_zookeeper面试题

zookeeper的分布式锁

• 上来直接创建一个锁节点下的一个接一个的临时顺序节点
• 如果自己不是第一个节点，就对自己上一个节点加监听器（Watcher机制）
• 只要上一个节点释放锁，自己就排到前面去了，相当于是一个排队机制。

而且用临时顺序节点，如果某个客户端创建临时顺序节点之后，自己宕机了，zk感知到那个客户端宕机，会自动删除对应的临时顺序节点，相当于自动释放锁，或者是自动取消自己的排队。解决了惊群效应

应用场景

(1) 数据发布/订阅: 配置中心
(2) 负载均衡: 提供服务者列表
(3) 命名服务: 提供服务名到服务地址的映射
(4)分布式协调/通知: watch机制和临时节点，获取各节点的任务进度，通过修改节点发出通知
(5)集群管理: 是否有机器退出和加入、选举 master
(7)分布式锁
(8)分布式队列
第一类，在约定目录下创建临时目录节点，监听节点数目是否是要求的数目,
第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。在特定的目录下创建PERSISTENT SEQUENTIAL 节点，创建成功时Watcher 通知等待的队列，队列删除序列号最小的节点用以消费。此场景下Zookeeper 的 znode 用于消息存储，znode 存的数据就是消息队列中的消息内容，SEQUENTIAL 序列号就是消息的编号，按序取出即可。由于创建的节点是持久化的，所以不必担心队列消息的丢失问题。

请谈谈ZooKeeper对事务性的支持

ZooKeeper对于事务性的支持主要依赖于四个函数，zoo_create_op_init，o_delete_op_init,zoo_set op init以及zoo check op init。
每一个函数都会在客户端初始化一个operation，客户端程序有义务保留这些operations。当准备好一个事务中的所有操作后，可以使用z0o_multi来提交所有的操作，由zookeeper服务来保证这一系列操作的原子性。也就是说只要其中有一个操作失败了，相当于此次提交的任何一个操作都没有对服务端的数据造成影响。Zoo multi的返回值是第一个失败操作的状态信号。
zookeeper 采用了全局递增的事务 Id 来标识，所有的 proposal（提议）都在被提出的时候加上了 zxid，zxid 实际上是一个 64 位的数字，高 32 位是epoch（ 时期; 纪元; 世; 新时代）用来标识 leader 周期，如果有新的 leader 产生出来，epoch会自增，低 32 位用来递增计数。当新产生 proposal 的时候，会依据数据库的两阶段过程，首先会向其他的 server 发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行。

ZAB协议

ZAB协议

ZAB 和 Paxos 算法的联系与区别

相同点：
（1）两者都存在一个类似于 Leader 进程的角色，由其负责协调多个 Follower进程的运行
（2）Leader 进程都会等待超过半数的 Follower 做出正确的反馈后，才会将一个提案进行提交
（3）ZAB 协议中，每个 Proposal 中都包含一个 epoch 值来代表当前的Leader周期，Paxos 中名字为 Ballot
不同点：
ZAB 用来构建高可用的分布式数据主备系统（Zookeeper），Paxos 是用来构建分布式一致性状态机系统。

简述zk中的观察者机制

peerType=observer
server.1:1ocalhost:2181:3181:observer

观察者的设计是希望能动态扩展zookeeper集群又不会降低写性能
如果扩展节点是follower，则写入操作提交时需要同步的节点数会变多，导致写入性能下降，而follower又是参与投票的、也会导致投票成本增加
observer是一种新的节点类型，解决扩展问题的同时，不参与投票、只获取投票结果，同时也可以处理读写请求，写请求转发给leader。负责接收leader同步过来的提交数据，observer的节点故障也不会影响集群的可用性
陪数据中心部署。把节点分散到多个数据中心可能因为网络的延迟会极大拖慢系统。使用observer的话，更新操作都在一个单独的数据中心来处理，并发送到其他数据中心，让其他数据中心的节点消费数据。
无法完全消除数据中心之间的网络延迟，因为observer需要把更新请求转发到另一个数据中心的leader，并处理同步消息，网络速度极慢的话也会有影响，它的优势是为本地读请求提供快速响应。

服务器角色

Leader
（1）事务请求的唯一调度和处理者，保证集群事务处理的顺序性
（2）集群内部各服务的调度者
Follower
（1）处理客户端的非事务请求，转发事务请求给 Leader 服务器
（2）参与事务请求 Proposal 的投票
（3）参与 Leader 选举投票
Observer
（1）3.0 版本以后引入的一个服务器角色，在不影响集群事务处理能力的基础上提升集群的非事务处理能力
（2）处理客户端的非事务请求，转发事务请求给 Leader 服务器
（3）不参与任何形式的投票

数据模型和节点类型

Zookeeper 提供一个多层级的节点命名空间（节点称为 znode）。与文件系统不同的是，这些节点都可以设置关联的数据，而文件系统中只有文件节点可以存放数据而目录节点不行。
Zookeeper 为了保证高吞吐和低延迟，在内存中维护了这个树状的目录结构，这种特性使得 Zookeeper 不能用于存放大量的数据，每个节点的存放数据上限为1M。

（1）PERSISTENT-持久节点
除非手动删除，否则节点一直存在于 Zookeeper 上
（2）EPHEMERAL-临时节点
临时节点的生命周期与客户端会话绑定，一旦客户端会话失效（客户端与zookeeper 连接断开不一定会话失效），那么这个客户端创建的所有临时节点都会被移除。
（3）PERSISTENT_SEQUENTIAL-持久顺序节点基本特性同持久节点，只是增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。
（4）EPHEMERAL_SEQUENTIAL-临时顺序节点
基本特性同临时节点，增加了顺序属性，节点名后边会追加一个由父节点维护的自增整型数字。

能干嘛（命名服务，配置管理，集群管理）

命名服务:
通过指定的名字来获取资源或者服务地址。Zookeeper可以创建一个全局唯一的路径，这个路径就可以作为一个名字。被命名的实体可以是集群中的机器，服务的地址，或者是远程的对象等。一些分布式服务框架(RPC.RMI)中的服务地址列表，通过使用命名服务，客户端应用能够根据特定的名字来获取资源的实体、服务地址和提供者信息等
配置管理
实际项目开发中，经常使用.properties或者xml需要配置很多信息，如数据库连接信息、fps地址端口等等。程序分布式部署时，如果把程序的这些配置信息保存在zk的znode节点下，当你要修改配置，即znode会发生变化时可以通过改变zk中某个目录节点的内容，利用watcher通知给各个客户端，从而更改配置。
集群管理:
集群管理包括集群监控和集群控制，就是监控集群机器状态，剔除机器和加入机器。zookeeper可以方便集群机器的管理，它可以实时监控znode节点的变化，一旦发现有机器挂了，该机器就会与水断开连接，对应的临时目录节点会被删除，其他所有机器都收到通知。新机器加入也是类似。

讲下Zookeeper watch机制

客户端，可以通过在znode上设置watch，实现实时监听znode的变化Watch事件是一人一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端
。父节点的创建，修改，删除都会触发Watcher事件.
。子节点的创建，删除会触发Watcher事件.
一次性:一旦被触发就会移除，再次使用需要重新注册，因为每次变动都需要通知所有客户端，一次性可以减轻压力，3.6.0默认持久递归，可以触发多次
轻量:只通知发生了事件，不会告知事件内容，减轻服务器和带宽压力

Watcher 机制包括三个角色: 客户端线程、客户端的 WatchManager 以及 ZooKeeper 服务器
1.客户端向 ZooKeeper 服务器注册一个 Watcher 监听( getData()/getChildren()/exist()）
2.把这个监听信息存储到客户端的 WatchManager 中
3.当ZooKeeper 中的节点发生变化时，会通知客户端，客户端会调用相应 Watcher 对象中的回调方法。watch回调是串行同步的

CAP理论，BASE理论

Consistency (一致性)：
在分布式系统中的所有数据备份，在同一时刻是否同样的值。
Availability (可用性):
即服务一直可用，而且是正常响应时间。系统能够很好的为用户服务，不出现用户操作败或者访问超时等用户体验不好的情况。
Partition Tolerance (分区容错性):
大多数分布式系统都分布在多个子网络。每个子网络就叫做一个区（partition）。分区容错的意思是，区间通信可能失败。
CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们无法避免的。所以我们只能在一致性和可用性之间进行权衡，没有系统能同时保证这三点。要么选择CP、要么选择AP。

CP和AP：分区容错是必须保证的，当发生网络分区的时候，如果要继续服务，那么强一致性和可用性只能 2 选 1
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventuallyconsistent（最终一致性）
BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
基本可用：
响应时间上的损失: 正常情况下，处理用户请求需要 0.5s 返回结果，但是由于系统出故障，处理用户请求的时变为 3 s。
系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的部分非核心功能无法使用。
软状态：数据同步允许一定的延迟最终一致性：系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态，不要求实时

zookeeper面试题

zookeeper面试题