ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务 ，是 Google 的 Chubby 一个开源的实现，它是集群的管理者 ， 监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作 。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
客户端的读请求可以被集群中的任意一台机器处理 ，如果读请求在节点上注册了监听器，这个监听器也是由所连接的 zookeeper 机器来处理。对于写请求 ，这些请求会同时发给其他 zookeeper 机器并且达成一致后，请求才会返回成功 。因此，随着 zookeeper 的集群机器增多，读请求的吞吐会提高但是写请求的吞吐会下降 。 有序性是 zookeeper 中非常重要的一个特性，所有的更新都是全局有序的 ，每个更新都有一个唯一的时间戳 ， 这个时间戳称为 zxid（Zookeeper Transaction Id） 。而读请求只会相对于更新有序 ，也就是读请求的返回
4、Zab 协议有两种模式 - 恢复模式（选主）、广播模式（同步)
Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数 Server 完成了和 leader 的状态同步以后，恢复模式就结束了。状态同步保证了 leader 和 Server 具有相同的系统状态
1、Leaderelection（选举阶段-选出准Leader）：节点在一开始都处于选举阶段，只要有一个节点得到超半数节点的票数，它就可L当选准leader。只有到达广播阶段（broadcast）准leader才会成为真正的leader。这一阶段的目的是就是为了选出一个准leader，然后进入下一个阶段。
2、Discovery（发现阶段-接受提议、生成epoch、接受epoch）：在这个阶段，followers跟准leader进行通信，同步followers最近接收的事务提议。这个一阶段的主要目的是发现当前大多数节点接收的最新提议，并且准leader生成新的epoch，让followers接受，更新它们的acceptedEpoch一个follower只 会连接一个leader，如果有一个节点f认为另一个followerp是leader，f在尝试连接p时会被拒绝，f被拒绝之后，就会进入重新选举阶段。
3、Synchronization（同步阶段-同步follower副本）：同步阶段主要是利用leader前一阶段获得的最新提议历史，同步集群中所有的副本。只有当大多数节点都同步完成，准leader才会成为真正的leader。follower只会接收zxid比自己的lastZxid大的提议。
4、Broadcast（广播阶段-leader消息广播）：到了这个阶段，Zookeeper集群才能正式对外提供事务服务，并且leader可以进行消息广播。同时如果有新的节点加入，还需要对新节点进行同步。ZAB提交事务并不像2PC一样需要全部follower都ACK，只需要得到超过半数的节点的ACK就可以了。
7、Zookeeper 角色
Zookeeper 集群是一个基于主从复制的高可用集群，每个服务器承担如下三种角色中的一种
Leader：
-
一个 Zookeeper 集群同一时间只会有一个实际工作的 Leader，它会发起并维护与各 Follwer 及 Observer 间的心跳
-
所有的写操作必须要通过 Leader 完成再由 Leader 将写操作广播给其它服务器。只要有超过半数节点（不包括 observeer 节点）写入成功，该写请求就会被提交（类 2PC 协议）
Follower
-
一个 Zookeeper 集群可能同时存在多个 Follower，它会响应 Leader 的心跳，
-
Follower 可直接处理并返回客户端的读请求，同时会将写请求转发给 Leader 处理，
-
并且负责在 Leader 处理写请求时对请求进行投票。
Observer
角色与 Follower 类似，但是无投票权。Zookeeper 需保证高可用和强一致性，为了支持更多的客户端，需要增加更多Server；Server增多，投票阶段延迟增大，影响性能；引入Observer， Observer 不参与投票； Observers 接受客户端的连接，并将写请求转发给 leader 节点； 加入更多Observer 节点，提高伸缩性，同时不影响吞吐率。
zookeeper提供一个类似unix文件系统目录的多层级节点命名空间（节点称为znode）。与文件系统不同的是，这些节点都可以设置关联的数据，而文件系统中只有文件节点可以存放数据而目录节点不行。zookeeper为了保证高吞吐和低延迟，在内存中维护了这个树状的目录结构，这种特性使得zookeeper不能用于存放大量的数据，每个节点的存放数据上限为1M。
client 端会对某个 znode 建立一个watcher 事件，当该 znode 发生变化时，zk会主动通知 watch 这个 znode 的 client，然后 client 根据 znode 的变化来做出业务上的改变等。
watcher 的特点：
-
轻量级：一个 callback 函数。
-
异步性：不会 block 正常的读写请求。
-
主动推送：Watch 被触发时，由 Zookeeper 服务端主动将更新推送给客户端。
-
一次性：数据变化时，Watch 只会被触发一次。如果客户端想得到后续更新的通知，必须要在 Watch 被触发后重新注册一个 Watch。
-
仅通知：仅通知变更类型，不附带变更后的结果。
-
顺序性：如果多个更新触发了多个 Watch，那 Watch被触发的顺序与更新顺序一致。
使用 watch 的注意事项：
-
由于 watcher 是一次性的，所以需要自己去实现永久 watch。
-
如果被 watch 的节点频繁更新，会出现“丢数据”的情况。
-
watcher 数量过多会导致性能下降
11、zookeeper 的四种类型的 znode
-
PERSISTENT 持久化节点
-
PERSISTENT_SEQUENTIAL 顺序自动编号持久化节点，这种节点会根据当前已存 在的节点数自动加 1
-
EPHEMERAL 临时节点， 客户端 session 超时这类节点就会被自动删除
-
EPHEMERAL_SEQUENTIAL 临时自动编号节点
所谓集群管理无在乎两点：是否有机器退出和加入、选举 master。 对于第一点，所有机器约定在父目录下创建临时目录节点，然后监听父目录节点的子节点变化消息。一旦有机器挂掉，该机器与 zookeeper 的连接断开，其所创建的临时目录节点被删除，所有其他机器都收到通知：某个兄弟目录被删除，于是，所有人都知道：它上船了。
新机器加入也是类似，所有机器收到通知：新兄弟目录加入，highcount 又有了，对于第二点，我们稍微改变一下，所有机器创建临时顺序编号目录节点，每次选取编号最小的机器作为master 就好。
有了 zookeeper 的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是保持独占，另一个是控制时序。
保持独占，我们将 zookeeper 上的一个 znode 看作是一把锁，通过 createznode 的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。用完删除掉自己创建的 distribute_lock 节点就释放出锁。
控制时序，/distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选 master 一样，编号最小的获得锁，用完删除，依次方便。
16、获取分布式锁的流程
代码的实现主要是基于互斥锁，获取分布式锁的重点逻辑在于BaseDistributedLock，实现了基于 Zookeeper 实现分布式锁的细节。客户端需要找到比自己小的那个节点，然后对其调用 exist()方法，同时对其注册事件监听器。之后，让这个被关注的节点删除，则客户端的 Watcher 会收到相应通知，此时再次判断自己创建的节点是否是 locker 子节点中序号最小的，如果是则获取到了锁，如果不是则重复以上步骤继续获取到比自己小的一个节点并注册监听。当前这个过程中还需要许多的逻辑判断。
代码的实现主要是基于互斥锁，获取分布式锁的重点逻辑在于BaseDistributedLock，实现了基于 Zookeeper 实现分布式锁的细节。
17、zk 队列管理
两种类型的队列：
1、同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目
2、队列按照 FIFO 方式进行入队和出队操作。和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。在特定的目录下创建 PERSISTENT_SEQUENTIAL节点，创建成功时 Watcher 通知等待的队列，队列删除序列号最小的节点用以消费。此场景下 Zookeeper 的 znode 用于消息存储，znode 存储的数据就是消息队列中的消息内容，SEQUENTIAL 序列号就是消息的编号，按序取出即可。由于创建的节点是持久化的，所以不必担心队列消息的丢失问题。
18、zk 数据复制
Zookeeper 作为一个集群提供一致的数据服务，自然，它要在所有机器间做数据复制。数据复制的好处：
1、容错：一个节点出错，不致于让整个系统停止工作，别的节点可以接管它的工作；
2、提高系统的扩展能力 ：把负载分布到多个节点上，或者增加节点来提高系统的负载能力；
3、提高性能：让客户端本地访问就近的节点，提高用户访问速度。
从客户端读写访问的透明度来看，数据复制集群系统分下面两种：
1、写主(WriteMaster) ：对数据的修改提交给指定的节点。读无此限制，可以读取任何一个节点。这种情况下客户端需要对读与写进行区别，俗称读写分离；
2、写任意(Write Any)：对数据的修改可提交给任意的节点，跟读一样。这种情况下，客户端对集群节点的角色与变化透明。
对 zookeeper 来说，它采用的方式是写任意。通过增加机器，它的读吞吐能力和响应能力扩展性非常好，而写，随着机器的增多吞吐能力肯定下降（这也是它建立 observer 的原因），而响应能力则取决于具体实现方式，是延迟复制保持最终一致性，还是立即复制快速响应。
19、zk 是如何保证事物的顺序一致性
20、zk 集群下 server 工作状态
每个 Server 在工作过程中有四种状态：
-
-
LOOKING：当前 Server 不知道 leader 是谁，正在搜寻
-
LEADING：当前 server 角色为 leader
-
FOLLOWING：当前 server 角色为 follower
-
OBSERVING：当前 server 角色为 observer
-
当 leader 崩溃或者 leader 失去大多数的 follower，这时 zk 进入恢复模式，恢复模式需要重新选举出一个新的 leader，让所有的 Server 都恢复到一个正确的状态。Zk 的选举算法有两种：一种是基于 basic paxos 实现的，另外一种是基于 fastpaxos 算法实现的。系统默认的选举算法为 fast paxos。
1、Zookeeper 选主流程(basic paxos)
- 选举线程由当前 Server 发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的 Server；
- 选举线程首先向所有 Server 发起一次询问(包括自己)；
- 选举线程收到回复后，验证是否是自己发起的询问(验证 zxid 是否一致)，然后获取对方的 id(myid)，并 存储到当前询问对象列表中，最后获取对方提议的 leader 相关信息(id,zxid)，并将这些信息存储到当次选举的投票记录表中；
- 收到所有 Server 回复以后，就计算出 zxid 最大的那个 Server，并将这个 Server 相关信息设置成下一次要投票的 Server；
- 线程将当前 zxid 最大的 Server 设置为当前 Server 要推荐的Leader，如果此时获胜的 Server 获得 n/2 + 1 的 Server 票数，设置当前推荐的leader 为获胜的 Server，将根据获胜的 Server 相关信息设置自己的状态，否则，继续这个过程，直到 leader 被选举出来。 通过流程分析我们可以得 出：要使Leader获得多数Server的支持，则Server总数必须是奇数2n+1，且存活的Server的数目不得少于 n+1. 每个 Server 启动后都会重复以上流程。在恢复模式下，如果是刚从崩溃状态恢复的或者刚启动的 server 还会从磁盘快照中恢复数据和会 话信息，zk 会记录事务日志并定期进行快照，方便在恢复时进行状态恢复。
目前有 5 台服务器，每台服务器均没有数据，它们的编号分别是 1,2,3,4,5,按编号依次启动，它们 的选择举过程如下：
-
服务器 1 启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器 1 的状态一直属于 Looking。
-
服务器 2 启动，给自己投票，同时与之前启动的服务器 1 交换结果，由于服务器 2 的编号 大所以服务器 2 胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是 LOOKING。
-
服务器 3 启动，给自己投票，同时与之前启动的服务器 1,2 交换信息，由于服务器 3 的编 号最大所以服务器 3 胜出，此时投票数正好大于半数，所以服务器 3 成为领导者，服务器 1,2 成为小弟。
-
服务器 4 启动，给自己投票，同时与之前启动的服务器 1,2,3 交换信息，尽管服务器 4 的 编号大，但之前服务器 3 已经胜出，所以服务器 4 只能成为小弟。
-
服务器 5 启动，后面的逻辑同服务器 4 成为小弟。
-
2、Zookeeper 选主流程(fast paxos) fast paxos 流程是在选举过程中，某 Server首先向所有 Server 提议自己要成为 leader，当其它 Server 收到提议以后，解决epoch 和 zxid 的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选举出 Leader。
选完 Leader 以后，zk 就进入状态同步过程。
-
Leader 等待 Follower 和 Observer 连接；
-
Follower 连接 leader，将最大的 zxid 发送给 leader；
-
Leader 根据 follower 的 zxid 确定同步点；
-
完成同步后通知 follower 已经成为 uptodate 状态；
-
Follower 收到 uptodate 消息后，又可以重新接受 client 的请求进行服务 了
-
数据同步的 4 种方式：
1、SNAP-全量同步
• 条件：peerLastZxid<minCommittedLog
• 说明：证明二者数据差异太大，follower 数据过于陈旧，leader 发送快照 SNAP 指令给 follower 全量同步数据，即 leader 将所有数据全量同步到 follower
2、DIFF-增量同步
• 条件：minCommittedLog<=peerLastZxid<=maxCommittedLog
• 说明：证明二者数据差异不大，follower 上有一些 leader 上已经提交的提议 proposal未同步，此时需要增量提交这些提议即可
3、TRUNC-仅回滚同步
• 条件：peerLastZxid>minCommittedLog
• 说明：证明 follower 上有些提议 proposal 并未在 leader 上提交，follower 需要回滚到 zxid 为 minCommittedLog 对应的事务操作
4、TRUNC+DIFF-回滚+增量同步
• 条件：minCommittedLog<=peerLastZxid<=maxCommittedLog
• 说明：leader a 已经将事务 truncA 提交到本地事务日志中，但没有成功发起 proposal协议进行投票就宕机了；然后集群中剔除原 leader a 重新选举出新 leader b，又提交了若干新的提议 proposal，然后原 leader a 重新服务又加入到集群中说明：此时a,b 都有一些对方未提交的事务，若 b 是 leader, a 需要先回滚 truncA 然后增量同步新 leader b 上的数据。
23、分布式通知和协调
24、Zookeeper 工作原理
- Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式和广播模式。
- 当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。
- 状态同步保证了leader和server具有相同的系统状态Java研发军团整理https://www.ycbbs.vip=
- 一旦leader已经和多数的follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个server加入zookeeper服务中，它会在恢复模式下启动，发现leader，并和leader进行状态同步。待到同步结束，它也参与消息广播。Zookeeper服务一直维持在Broadcast状态，直到leader崩溃了或者leader失去了大部分的followers支持。
- 广播模式需要保证proposal被按顺序处理，因此zk采用了递增的事务id号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了zxid。
- 实现中zxid是一个64为的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch。低32位是个递增计数。
- 当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的server都恢复到一个正确的状态
25、zookeeper watch 机制
Watch机制官方声明：一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们。Zookeeper机制的特点：
1、一次性触发数据发生改变时，一个watcherevent会被发送到client，但是client只会收到一次这样的信息。
2、watcherevent异步发送watcher的通知事件从server发送到client是异步的，这就存在一个问题，不同的客户端和服务器之间通过socket进行通信，由于网络延迟或其他因素导致客户端在不通的时刻监听到事件，由于Zookeeper本身提供了orderingguarantee，即客户端监听事件后，才会感知它所监视znode发生了变化。所以我们使用Zookeeper不能期望能够监控到节点每次的变化。Zookeeper只能保证最终的一致性，而无法保证强一致性。
3、数据监视Zookeeper有数据监视和子数据监视getdata()andexists()设置数据监视，getchildren()设置了子节点监视。
4、注册watchergetData、exists、getChildren 5、触发watchercreate、delete、setData
6、setData()会触发znode上设置的datawatch（如果set成功的话）。一个成功的create()操作会触发被创建的znode上的数据watch，以及其父节点上的childwatch。而一个成功的delete()操作将会同时触发一个znode的datawatch和childwatch（因为这样就没有子节点了），同时也会触发其父节点的childwatch。
7、当一个客户端连接到一个新的服务器上时，watch将会被以任意会话事件触发。当与一个服务器失去连接的时候，是无法接收到watch的。而当client重新连接时，如果需要的话，所有先前注册过的watch，都会被重新注册。通常这是完全透明的。只有在一个特殊情况下，watch可能会丢失：对于一个未创建的znode的existwatch，如果在客户端断开连接期间被创建了，并且随后在客户端连接上之前又删除了，这种情况下，这个watch事件可能会被丢失。
8、Watch是轻量级的，其实就是本地JVM的Callback，服务器端只是存了是否有设置了Watcher的布尔类型
26、zookeeper 负载均衡和 nginx 负载均衡区别
zk 的负载均衡是可以调控，nginx 只是能调权重，其他需要可控的都需要自己写插件；但是 nginx 的吞吐量比zk 大很多，应该说按业务选择用哪种方式
27、机器中为什么会有 leader？
在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行， 其他的机器可以共享这个结果 ，这样可以大大 减少重复计算 ， 提高性能 ，于是就需要进行 leader 选举。
28、zk节点宕机如何处理？
Zookeeper本身也是集群，推荐配置不少于3个服务器。Zookeeper自身也要保证当一个节点宕机时，其他节点会继续提供服务。如果是一个Follower宕机，还有2台服务器提供访问，因为Zookeeper上的数据是有多个副本的，数据并不会丢失；如果是一个Leader宕机，Zookeeper会选举出新的Leader。ZK集群的机制是只要超过半数的节点正常，集群就能正常提供服务。只有在ZK节点挂得太多，只剩一半或不到一半节点能工作，集群才失效。所以3个节点的cluster可以挂掉1个节点(leader可以得到2票>1.5)2个节点的cluster就不能挂掉任何1个节点了(leader可以得到1票<=1)
29、集群支持动态添加机器吗？
其实就是水平扩容了，Zookeeper 在这方面不太好。两种方式：
- 全部重启：关闭所有 Zookeeper 服务，修改配置之后启动。不影响之前客户端的会话。
- 逐个重启：在过半存活即可用的原则下，一台机器重启不影响整个集群对外提供服务。这是比较常用的方式。
3.5 版本开始支持动态扩容
30、Zookeeper对节点的watch监听通知是永久的吗？为什么不是永久的?
不是。官方声明：一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们。为什么不是永久的，举个例子，如果服务端变动频繁，而监听的客户端很多情况下，每次变动都要通知到所有的客户端，给网络和服务器造成很大压力。一般是客户端执行getData(“/节点A”,true)，如果节点A发生了变更或删除，客户端会得到它的watch事件，但是在之后节点A又发生了变更，而客户端又没有设置watch事件，就不再给客户端发送。在实际应用中，很多情况下，我们的客户端不需要知道服务端的每一次变动，我只要最新的数据即可
31、ZAB和Paxos算法的联系与区别？
相同点：
1、两者都存在一个类似于Leader进程的角色，由其负责协调多个Follower进程的运行
2、Leader进程都会等待超过半数的Follower做出正确的反馈后，才会将一个提案进行提交
3、ZAB协议中，每个Proposal中都包含一个epoch值来代表当前的Leader周期，Paxos中名字为Ballot
不同点：
ZAB用来构建高可用的分布式数据主备系统（Zookeeper），Paxos是用来构建分布式一致性状态机系统。