[口试题]Zookeeper

• [口试题]Java【根本】
  
• [口试题]Java【假造机】
  
• [口试题]Java【并发】
  
• [口试题]Java【聚集】
  
• [口试题]MySQL
  
• [口试题]Maven
  
• [口试题]Spring Boot
  
• [口试题]Spring Cloud
  
• [口试题]Spring MVC
  
• [口试题]Spring
  
• [口试题]MyBatis
  
• [口试题]Nginx
  
• [口试题]缓存
  
• [口试题]Redis
  
• [口试题]消息队列
  
• [口试题]Kafka
  
• [口试题]RabbitMQ
  
• [口试题]MongoDB
  
• [口试题]Dubbo
  
• [口试题]Git
  
• [口试题]Jenkins
  
• [口试题]Linux
  
• [口试题]Netty
  
• [口试题]Zookeeper
  
• [口试题]盘算机网络
  
• [口试题]分库分表
  

Zookeeper 是什么？

ZooKeeper 是一个开放源码的分布式和谐服务，它是集群的管理者，监督着集群中各个节点的状态根据节点提交的反馈举行下一步公道利用。终极，将简朴易用的接口和性能高效、功能稳固的体系提供给用户。
分布式应用步伐可以基于 Zookeeper 实现诸如数据发布/订阅、负载均衡、定名服务、分布式和谐/关照、集群管理、Master 推选、分布式锁和分布式队列等功能。
Zookeeper 具有如下特性：

• 序次划一性(有序性)
  

   从同一个客户端发起的事件哀求，终极将会严格地按照其发起序次被应用到 Zookeeper 中去。有序性是 Zookeeper 中非常告急的一个特性。全部的更新都是全局有序的，每个更新都有一个唯一的时间戳，这个时间戳称为zxid(Zookeeper Transaction Id)。而读哀求只会相对于更新有序，也就是读哀求的返回效果中会带有这个 Zookeeper 最新的 zxid 。
  

• 原子性
  

   全部事件哀求的处理处罚效果在整个集群中全部呆板上的应用情况是划一的，即整个集群要么都乐成应用了某个事件，要么都没有应用。
  

• 单一视图
  

   无论客户端毗连的是哪个 Zookeeper 服务器，其看到的服务端数据模子都是划一的。
  

• 可靠性
  

   一旦服务端乐成地应用了一个事件，并完成对客户端的相应，那么该事件所引起的服务端状态变更将会不绝被保存，除非有另一个事件对其举行了变更。
  

• 及时性
  

   Zookeeper 包管在肯定的时间段内，客户端终极肯定可以或许从服务端上读取到最新的数据状态。
  Zookeeper 对于读写哀求有所差别：

• 客户端的读哀求可以被集群中的恣意一台呆板处理处罚，假如读哀求在节点上注册了监听器，这个监听器也是由所毗连的 Zookeeper 呆板来处理处罚。
  
• 对于写哀求，这些哀求会同时发给其他 Zookeeper 呆板而且告竣划一后，哀求才会返回乐成。因此，随着 Zookeeper 的集群呆板增多，读哀求的吞吐会进步但是写哀求的吞吐会降落。
  

🦅 Chubby 是什么？和 Zookeeper 对比你怎么看？

• Chubby 是 Google 的，完全实现 Paxos 算法，不开源。
  
• Zookeeper 是 Chubby 的开源实现，利用 ZAB 协议(Paxos 算法的变种)。
  

🦅 Zookeeper 的 Java 客户端都有哪些？

• Zookeeper 自带的 zkclient
  
• Apache 开源的 Curator
  

   现实项目中，采取 Curator 居多。由于，功能更加强大。
  详细的利用，可以看看 《ZK 客户端利用》 文章。
别的，Zookeeper 没有特殊好用的 GUI 工具，有须要的胖友，可以看看 ZooInspector ，凑活能用。
Zookeeper 的筹划目标？

• 1、简朴的数据结构，Zookeeper 使得分布式步伐可以或许通过一个共享的树形结构的名字空间来举行相互和谐，即 Zookeeper 服务器内存中的数据模子由一系列被称为 ZNode 的数据节点构成，Zookeeper 将全量的数据存储在内存中，以此来进步服务器吞吐、镌汰延长的目标。
  
• 2、可以构建集群 Zookeeper 集群通常由一组呆板构成，构成 Zookeeper 集群的而每台呆板都会在内存中维护当前服务器状态，而且每台呆板之间都相互通讯。
  
• 3、序次访问，对于来自客户端的每个更新哀求，Zookeeper 都会分配一个全局唯一的递增编号，这个编号反映了全部事件利用的先后序次。
  
• 4、高性能，Zookeeper 和 Redis 一样全量数据存储在内存中，100%读哀求压测 QPS 12-13W 。
  

   没详细测试过，比想象中的高。感爱好的胖友，可以看看 《ZooKeeper 的一个性能测试》 。
  Zookeeper 有哪些应用场景？

Zookeeper 的功能很强大，应用场景许多，联合我们现实工作中利用 Dubbo 框架的情况，Zookeeper 重要是做注册中央用。

• 基于 Dubbo 框架开辟的提供者、消耗者都向 Zookeeper 注册本身的 URL ，消耗者还能拿到并订阅提供者的注册 URL ，以便在后续步伐的实行中去调用提供者。
  
• 而提供者发生了变更，也会通过 Zookeeper 向订阅的消耗者发送关照。
  

固然，Zookeeper 能提供的不光仅云云，再比方：

• 同一定名服务。
  

定名服务是指通过指定的名字来获取资源或服务的所在，利用zk创建一个全局的路径，即时唯一的路径，这个路径就可以作为一个名字，指向集群中呆板大概提供服务的所在，又大概一个长途的对象等。

• 分布式锁服务。
  

   这个比力好明白，Zookeeper 实现的分布式锁的可靠性会比 Redis 实现的分布式锁高，固然相对来说，性能会低。
  

• 设置管理。
  

   比方说，Spring Cloud Config Zookeeper ，就实现了基于 Zookeeper 的 Spring Cloud Config 的实现，提供设置中央的服务。
  

• 注册与发现。
  

   是否有呆板参加或退出全部呆板约定在父目次下创建暂时目次节点，然后监听父目次节点下的子节点厘革。一旦有呆板挂掉，该呆板与 ZooKeeper 的毗连断开，其所创建的暂时目次节点也被删除，全部其他呆板都收到关照：某个节点被删除了。
  

• Master 推选。
  

   基于 Zookeeper 实现分布式和谐，从而实现主从的推选。这个在 Kafka、Elastic-Job 等等中央件，都有所利用到。
  

• 分布式锁。
  

   有了 ZooKeeper 的划一性文件体系，锁的标题变得容易。锁服务可以分成两类，一个是保持独占，另一个是控制时序。1、保持独占，我们把 znode 看作是一把锁，通过 createZnode 的方式来实现。全部客户端都去创建 /distribute_lock 节点，终极乐成创建的谁人客户端也即拥有了这把锁。用完删撤除本身创建的 /distribute_lock 节点就开释出锁。2、控制时序，/distribute_lock 已经预先存在，全部客户端在它下面创建暂时序次编号目次节点，和 Master 一样，编号最小的得到锁，用完删除，依次方便。
  

• 队列管理
  

   两种范例的队列。1、同队伍列，当一个队列的成员都聚齐时，这个队列才可用，否则不绝期待。在约定的目次下创建暂时目次节点，监听节点数量是否是我们要求的数量。2、队列按照 FIFO 方式举行入队和出队利用。和分布式锁服务中的控制时序的场景根本原理划一，入列有编号，出列按编号。创建 PERSISTENT_SEQUENTIAL 节点，创建乐成时 Watcher 关照期待的队列，队列删除序列号最小的节点以消耗。此场景下，znode 用于消息存储，znode 存储的数据就是消息队列中的消息内容，SEQUENTIAL 序列号就是消息的编号，按序取出即可。由于创建的节点是长期化的，以是不必担心队列消息丢失的标题。
  固然，详细的可以看看 《Zookeeper 技能浅析》 文章。别的，该问对 Zookeeper 的“特点”先容，也要重点看看。
上述的许多功能，在 Apache Curator 已经默认提供实现了，直接调用 API 即可利用。
🦅 作为服务注册中央，Eureka 比 Zookeeper 幸亏那边？
拜见 《作为服务注册中央，Eureka 比 Zookeeper 幸亏那边》 文章。
比力告急的缘故原由是，注册中央对可用性比划一性有更高的要求，也就是说，可以或许容忍在非常情况下，读取到几分钟前的数据。
Zookeeper 提供了什么？

• 1、文件体系。
  
• 2、关照机制。
  

Zookeeper 的文件体系是什么？

Zookeeper 提供一个多层级的节点定名空间(节点称为 znode)。与文件体系差别的是，这些节点都可以设置关联的数据，而文件体系中只有文件节点可以存放数据而目次节点不可。
Zookeeper 为了包管高吞吐和低延长，在内存中维护了这个树状的目次结构，这种特性使得 Zookeeper 不能用于存放大量的数据，每个节点的存放数据上限为 1M 。
🦅 Zookeeper 有哪几种节点范例？

• PERSISTENT 长期节点
  

   创建之后不绝存在，除非有删除利用，创建节点的客户端会话失效也不影响此节点。
  

• PERSISTENT_SEQUENTIAL 长期序次节点
  

   跟长期一样，就是父节点在创建下一级子节点的时间，纪录每个子节点创建的先后序次，会给每个子节点名加上一个数字后缀。
  

• EPHEMERAL 暂时节点
  

   创建客户端会话失效（留意是会话失效，不是毗连断了），节点也就没了。不能建子节点。
  

• EPHEMERAL_SEQUENTIAL 暂时序次节点
  

   根本特性同暂时节点，增长了序次属性，节点名后边会追加一个由父节点维护的自增整型数字。
  Elastic-Job-Lite 利用 Zookeeper 作为存储的明细：
Zookeeper 的关照机制是什么？

Zookeeper 允许客户端向服务端的某个 znode 注册一个 Watcher 监听，当服务端的一些指定变乱触发了这个 Watcher ，服务端会向指定客户端发送一个变乱关照来实现分布式的关照功能，然后客户端根据 Watcher 关照状态和变乱范例做出业务上的改变。
整个流程如下：
   详细的过程，下面每个小标题，举行分析。
  

• 第一步，客户端注册 Watcher 。
  
• 第二步，服务端处理处罚 Watcher 。
  
• 第三步，客户端回调 Watcher 。
  

Watcher 的特性总结：

• 1、一次性。
  

   无论是服务端照旧客户端，一旦一个 Watcher 被触发， Zookeeper 都会将其从相应的存储中移除。如许的筹划有效的减轻了服务端的压力，否则对于更新非常频仍的节点，服务端会不绝的向客户端发送变乱关照，无论对于网络照旧服务端的压力都非常大。留意哟，这个特性可以变成一个口试题「Zookeeper 对节点的 watch 监听关照是永世的吗？」。假如我们利用 Apache Curator 作为利用 Zookeeper 的客户端，它可以帮我们自动透明的实现连续的 watch 利用，非常方便。
  

• 2、客户端串行实行。
  

   客户端 Watcher 回调的过程是一个串行同步的过程。
  

• 3、轻量级 Watch 机制。
  

   Watcher 关照非常简朴，只会告诉客户端发生了变乱，而不会分析变乱的详细内容。客户端向服务端注册 Watcher 的时间，并不会把客户端真实的 Watcher 对象实体通报到服务端，仅仅是在客户端哀求中利用boolean 范例属性举行了标记。
  

• 4、Watcher event 异步发送 Watcher 的关照变乱从 Server 发送到Client 是异步的，这就存在一个标题，差别的客户端和服务器之间通过Socket 举行通讯，由于网络延长或其他因素导致客户端在不通的时候监听到变乱，由于 Zookeeper 本身提供了 ordering guarantee ，即客户端监听变乱后，才会感知它所监督 znode 发生了厘革。以是我们利用 Zookeeper 不能渴望可以或许监控到节点每次的厘革。
  

Zookeeper 只能包管终极的划一性，而无法包管强划一性。

• 5、可以注册 Watcher 的利用：getData、exists、getChildren 。
  
• 6、可以触发 Watcher 的利用：create、delete、setData 。
  
• 7、当一个 Client 毗连到一个新的服务器上时，watch 将会被以恣意会话变乱触发。当与一个服务器失去毗连的时间，是无法吸收到 watch 的。而当 Client 重新毗连时，假如须要的话，全部先前注册过的watch ，都会被重新注册。通常这是完全透明的。只有在一个特殊情况下，watch 大概会丢失：对于一个未创建的 znode 的 exists watch ，假如在客户端断开毗连期间被创建了，而且随后在客户端毗连上之前又删除了，这种情况下，这个 watch 变乱大概会被丢失。
  

看了这么多特性总结，最最最告急的是【一次性】。
下面三个步调，选择性相识即可。口试假如问到，就当倒霉。
🦅 第一步，客户端注册 Watcher 实现？

• 1、调用 getData、getChildren、exist 三个 API ，传入Watcher 对象。
  
• 2、标记哀求 request ，封装 Watcher 到 WatchRegistration 。
  
• 3、封装成 Packe t对象，发服务端发送 request 。
  
• 4、收到服务端相应后，将 Watcher 注册到 ZKWatcherManager 中举行管理。
  
• 5、哀求返回，完成注册。
  

🦅 第二步，服务端处理处罚 Watcher 实现？

• 1、服务端吸收 Watcher 并存储。
  

   吸收到客户端哀求，处理处罚哀求判断是否须要注册 Watcher ，须要的话将数据节点的节点路径和 ServerCnxn(ServerCnxn 代表一个客户端和服务端的毗连，实现了 Watcher 的 process 接口，此时可以看成一个 Watcher 对象)存储在 WatcherManager 的 WatchTable 和 Watch2Paths 中去。
  

• 2、Watcher 触发。
  

   以服务端吸收到 setData 事件哀求触发 NodeDataChanged 变乱为例：封装 WatchedEvent ：将关照状态（SyncConnected）、变乱范例（NodeDataChanged）以及节点路径封装成一个WatchedEvent对象查询 Watcher ：从 WatchTable 中根据节点路径查找 Watcher 。没找到 ：分析没有客户端在该数据节点上注册过 Watcher 。找到 ：提取并从 WatchTable 和 Watch2Paths 中删除对应 Watcher (从这里可以看出 Watcher 在服务端是一次性的，触发一次就失效了)。
  

• 3、调用 process 方法来触发 Watcher 。
  

   这里 process 重要就是通过 ServerCnxn 对应的 TCP 毗连发送 Watcher 变乱关照。
  🦅 第三步，客户端回调 Watcher 实现？
客户端 SendThread 线程吸收变乱关照，交由 EventThread 线程回调Watcher 。
客户端的 Watcher 机制同样是一次性的，一旦被触发后，该 Watcher 就失效了。
Zookeeper 采取什么权限控制机制？

   在网上看到一个「你们的 Zookeeper 的节点加密是用的什么方式？」标题，应该也是问这个。
  现在，在 Linux/Unix 文件体系中，利用 UGO(User/Group/Others) 权限模子，也是利用最广泛的权限控制方式。是一种粗粒度的文件体系权限控制模式。
   一样平常我们管理配景，采取的 RBAC 居多，和 UGO 比力雷同，差别在于一样平常将权限分配给 Role ，而不是直接给 User 。
  对于 Zookeeper ，它采取 ACL（Access Control List）访问控制列表。包罗三个方面：

• 权限模式（Scheme）
  

   IP ：从 IP 所在粒度举行权限控制【常用】Digest ：最常用，用雷同于 username:password 的权限标识来举行权限设置，便于区分差别应用来举行权限控制。World ：最开放的权限控制方式，是一种特殊的 digest 模式，只有一个权限标识 “world:anyone” 。Super ：超等用户。
  

• 授权对象
  

   授权对象指的是权限赋予的用户或一个指定实体，比方 IP 所在或是呆板等。
  

• 权限 Permission
  

   CREATE ：数据节点创建权限，允许授权对象在该 znode 下创建子节点。DELETE ：子节点删除权限，允许授权对象删除该数据节点的子节点。READ ：数据节点的读取权限，允许授权对象访问该数据节点并读取其数据内容或子节点列表等。WRITE ：数据节点更新权限，允许授权对象对该数据节点举行更新利用。ADMIN ：数据节点管理权限，允许授权对象对该数据节点举行 ACL 干系设置利用。
  🦅 Chroot 特性是什么？
Zookeeper 3.2.0 版本后，添加了 Chroot 特性。该特性允许每个客户端为本身设置一个定名空间。假如一个客户端设置了 Chroot ，那么该客户端对服务器的任何利用，都将会被限定在其本身的定名空间下。
通过设置 Chroot ，可以或许将一个客户端应用于 Zookeeper 服务端的一颗子树相对应，在那些多个应用公用一个 Zookeeper 进群的场景下，对实现差别应用间的相互隔离非常有资助。
Zookeeper 的会话管理是怎么样的？

ZooKeeper 的每个客户端都维护一组服务端信息，在创建毗连时由应用指定，客户端随机选择一个服务端举行毗连，毗连乐成后，服务端为每个毗连分配一个唯一标识。

• 客户端在创建毗连时可以指定溢出时间，客户端会周期性的向服务端发送 PING 哀求来保持毗连。
  

   假如客户端非常下线，大概网络标题，导致一段时间没心跳给 Zookeeper 服务端，则会被 Zookeeper 标记为下线。
  

• 当客户端检测到与服务端断开毗连后，客户端将自动选择服务端列表中的另一个服务端举行重连。客户端允许应用修改服务端列表，但修改大概导致客户端与服务端的重连。
  

详细的，保举阅读如下两篇文章：

• 《ZooKeeper session 管理》
  
• 《ZooKeeper 技能内幕：会话》 更原理层面。
  

Zookeeper 的摆设方式？

Zookeeper 有两种摆设方式：

• 1、单机
  
• 2、集群
  

   Zookeeper 集群，是一个由多个 Server 构成，一个 Leader，多个 Follower。（这个差别于我们常见的 Master/Slave 模式）Leader 为客户端服务器提供读写服务，除了 Leader 外其他的呆板只能提供读服务。每个 Server 生存一份数据副本全数据划一，分布式读 Follower ，写由 Leader 实行更新哀求转发，由 Leader 实行更新哀求序次举行，来自同一个 Client 的更新哀求按其发送序次依次实行数据更新原子性，一次数据更新要么乐成，要么失败。全局唯一数据视图，Client 无论毗连到哪个 Server，数据视图都是划一的及时性，在肯定变乱范围内，Client 能读到最新数据。
  一样平常来说，测试情况摆设单机，而生产情况必须必须必须摆设集群。
🦅 集群中的呆板脚色有哪些？
集群中一共有三种脚色：

• 1、Leader
  

   事件哀求的唯一调治和处理处罚者，包管集群事件处理处罚的序次性。集群内部各服务的调治者。
  

• 2、Follower
  

   处理处罚客户端的非事件哀求，转发事件哀求给 Leader 服务器。到场事件哀求 Proposal 的投票。到场 Leader 推选投票。
  

• 3、Observer
  

   3.3.0 版本以后引入的一个服务器脚色，在不影响集群事件处理处罚本领的根本上提拔集群的非事件处理处罚本领。处理处罚客户端的非事件哀求，转发事件哀求给 Leader 服务器不到场任何情势的投票。假如 ZooKeeper 集群的读取负载很高，大概客户端多到跨机房，可以设置一些 Observer 服务器，以进步读取的吞吐量。Observer 和 Follower 比力相似，只有一些小区别：起首 Observer 不属于法定人数，即不参加推选也不相应发起，也不到场写利用的“过半写乐成”计谋；其次是 Observer 不须要将事件长期化到磁盘，一旦 Observer 被重启，须要从 Leader 重新同步整个名字空间。
  在一个集群中，最少须要 3 台。大概包管 2N + 1 台，即奇数。为什么包管奇数？重要是为了推选算法。
🦅 集群假如有 3 台呆板，挂掉 1 台集群还能工作吗？挂掉 2 台呢？
记着一个原则：过半存活即可用。以是挂掉 1 台可以继续工作，挂掉 2 台不可以工作。
🦅 集群支持动态添加呆板吗？
在 3.5 版本开始，支持动态扩容。
而在 3.5 版本之前，Zookeeper 在这方面不太好。以是须要如下两种方式：

• 全部重启：关闭全部 Zookeeper 服务，修改设置之后启动。不影响之前客户端的会话。
  
• 逐个重启：顾名思义。这是比力常用的方式。
  

🦅 Zookeeper 下 Server 工作状态？
服务用具有四种状态，分别是：

• LOOKING 探求 Leader 状态
  

   当服务器处于该状态时，它会以为当前集群中没有 Leader ，因此须要进入 Leader 推选状态。
  

• FOLLOWING 跟随者状态
  

   表明当前服务器脚色是 Follower 。
  

• LEADING 领导者状态
  

   表明当前服务器脚色是 Leader 。
  

• OBSERVING 观察者状态
  

表明当前服务器脚色是 Observer 。
ZooKeeper 的工作原理？
ZooKeeper 的焦点是原子广播，这个机制包管了各个 Server 之间的同步。实现这个机制的协议叫做 Zab 协议。Zab 协议有两种模式，它们分别是规复模式（选主）和广播模式（同步）：

• 选主：当服务启动大概 Leader 瓦解后，Zab 就进入了规复模式，当新的 Leader 被推选出来，且大多数 Server 完成了和 Leader 的状态同步以后，规复模式就竣事了。
  

   更加详细的形貌。当整个 Zookeeper 集群刚刚启动，大概 Leader 服务器宕机、重启大概网络故障导致不存在过半的服务器与 Leader服务器保持正常通讯时，全部历程（服务器）进入瓦解规复模式。起首，推选产生新的Leader服务器。然后，集群中 Follower 服务器开始与新的 Leader 服务器举行数据同步。当集群中高出半数呆板与该Leader服务器完成数据同步之后，退出规复模式进入消息广播模式，
  

• 同步：状态同步包管了 Leader 和 Server 具有雷同的体系状态。
  

   更加详细的形貌。Leader 服务器开始吸收客户端的事件哀求，天生事件提案来举行事件哀求处理处罚。
  🦅 ZooKeeper 是怎样包管事件的序次划一性的？
ZooKeeper 采取了递增的事件 id 来辨认，全部的 proposal（发起）都在被提出的时间加上了 zxid 。zxid 现实上是一个 64 位数字。

• 高 32 位是 epoch 用来标识 Leader 是否发生了改变，假如有新的 Leader 产生出来，epoch会自增。
  
• 低 32 位用来递增计数。
  

当新产生的 peoposal 的时间，会依据数据库的两阶段过程，起首会向其他的 Server 发失事件实行哀求，假如高出半数的呆板都能实行而且可以或许乐成，那么就会开始实行。
🦅 ZooKeeper 集群中个服务器之间是怎样通讯的？
Leader 服务器会和每一个 Follower/Observer 服务器都创建 TCP 毗连，同时为每个 Follower/Observer 都创建一个叫做 LearnerHandler 的实体。

• LearnerHandler 重要负责 Leader 和 Follower/Observer 之间的网络通讯，包罗数据同步，哀求转发和 Proposal 发起的投票等。
  
• Leader 服务器生存了全部 Follower/Observer 的 LearnerHandler 。
  

🦅 ZAB 和 Paxos 算法的接洽与区别？
Paxos 算法是分布式推选算法，Zookeeper 利用的 ZAB 协议（Zookeeper 原子广播）。
二者有雷同的地方：

• 都有一个 Leader，用来和谐 N 个 Follower 的运行
  
• Leader 要期待超半数的 Follower做 出准确反馈之后才举行提案。
  
• 二者都有一个值来代表 Leader 的周期。ZAB 协议中，每个 Proposal 中都包罗一个 epoch 值来代表当前的Leader周期，Paxos中名字为 Ballot 。
  

差别的地方在于：

• ZAB 用来构建高可用的分布式数据主备体系（Zookeeper），Paxos 是用来构建分布式划一性状态机体系。
  

Paxos 算法、ZAB 协议要想讲清楚可不是一时半会的事儿，自 1990 年莱斯利·兰伯特提出 Paxos 算法以来，由于艰涩难懂并没有受到器重。后续几年，兰伯特通过好几篇论文对其举行更进一步地表明，也直到 06 年谷歌发表了三篇论文，选择 Paxos 作为 Chubby cell 的划一性算法，Paxo s才真正盛行起来。
对于平常开辟者来说，尤其是学习利用 Zookeeper 的开辟者明白一点就好：分布式 Zookeeper 推选 Leader 服务器的算法，与 Paxos 有很深的关系。
Zookeeper 的推选过程？

当 Leader 瓦解，大概 Leader 失去大多数的 Follower，这时 Zookeeper 进入规复模式，规复模式须要重新推选出一个新的 Leader，让全部的 Server 都规复到一个准确的状态。
Zookeeper 的推选算法有两种：一种是基于 basic paxos 实现的，别的一种是基于 fast paxos 算法实现的。体系默认的推选算法为 fast paxos 。
🦅 Zookeeper 选主流程(basic paxos)？
   选择性相识。
  

• 1、推选线程由当前 Server 发起推选的线程担当，其重要功能是对投票效果举行统计，并选出保举的 Server 。
  
• 2、推选线程起首向全部 Server 发起一次扣问(包罗本身)。
  
• 3、推选线程收到复兴后，验证是否是本身发起的扣问(验证 zxid 是否划一)，然后获取对方的 id(myid)，并存储到当前扣问对象列表中，末了获取对方发起的 Leader干系信息(id，zxid)，并将这些信息存储到当次推选的投票纪录表中。
  
• 4、收到全部 Server 复兴以后，就盘算出 zxid 最大的谁人 Server ，并将这个 Server 干系信息设置成下一次要投票的 Server 。
  
• 5、线程将当前 zxid 最大的 Server 设置为当前 Server 要保举的 Leader ，假如此时得胜的 Server 得到 n/2+1 的 Server 票数，设置当前保举的 Leader 为得胜的 Server ，将根据得胜的 Server 干系信息设置本身的状态，否则，继续这个过程，直到 Leader 被推选出来。
  

通过流程分析我们可以得出：要使 Leader 得到多数 Server 的支持，则 Server 总数必须是奇数 2n+1 ，且存活的 Server 的数量不得少于n+1 。每个 Server 启动后都会重复以上流程。
在规复模式下，假如是刚从瓦解状态规复的大概刚启动的 Server 还会从磁盘快照中规复数据和会话信息，Zookeeper 会纪录事件日记并定期举行快照，方便在规复时举行状态规复。
🦅 Zookeeper 选主流程(fast paxos)？
   重点相识。这块在 《Zookeeper 源码分析 —— Zookeeper Leader 推选算法》 写的比力详细。
  由于 LeaderElection 收敛速率较慢，以是 Zookeeper 引入了 FastLeaderElection 推选算法，FastLeaderElection 也成了Zookeeper默认的Leader推选算法。
FastLeaderElection 是标准的 Fast Paxos 的实现。它起首向全部 Server 发起本身要成为 Leader ，当别的 Server 收到发起以后，办理 epoch 和 zxid 的辩论，并继续对方的发起，然后向对方发送继续发起完成的消息。重复这个流程，末了肯定能推选出Leader。
FastLeaderElection 算法通过异步的通讯方式来网络别的节点的选票，同时在分析选票时又根据投票者的当前状态来作差别的处理处罚，以加速 Leader 的推选历程。
🦅 为什么 Zookeeper 集群保举节点数是单数？
在统计投票时，有个过半的概念，大于集群呆板数量的一半，即大于或即是(n/2+1)。那么我们来看看如下的统计：
集群数量至少正常运行数量允许挂掉的数量22 的半数为 1，半数以上最少为 2033 的半数为 1.5，半数以上最少为 2144 的半数为 2，半数以上最少为 3155 的半数为 2.5，半数以上最少为 3266 的半数为 3，半数以上最少为 42通过以上可以发现：

• 3 台服务器和 4 台服务器都最多允许 1 台服务器挂掉，5 台服务器和 6 台服务器都最多允许 2 台服务器挂掉，显着 4 台服务器资源高于 3 台服务器资源，6 台服务器资源高于 5 服务器资源。
  
• 这是由于半数以上投票通过决定的。以是，Zookeeper 集群保举节点数是单数。
  

简朴的来说，节省资源！
别的，由于 Zookeeper 利用划一性协议，过多的节点，反倒会低沉性能。😈
🦅 Zookeeper 是否需存在脑裂？
按原理说，Zookeeper 推选不会存在脑裂标题，由于须要 n / 2 + 1 投票通过，才气实行对应的写利用。但是听朋侪说，现实场景下，貌似发生过脑裂标题。

• 《Zookeeper 已经分布式情况中的假死脑裂》
  

以为存在脑裂标题，以及提供怎么办理。

• 《zookeeper（二）常见标题汇总》
  

以为不会存在脑裂标题。
🦅 呆板中为什么会有 Leader？
在分布式情况中，有些业务逻辑只须要集群中的某一台呆板举行实行，其他的呆板可以共享这个效果，如允许以大大镌汰重复盘算，进步性能，于是就须要举行 Leader 推选。
Zookeeper 的同步流程？

选完 Leader 以后，Zookeeper 就进入状态同步过程。

• 1、Leader 期待 Server 毗连。
  
• 2、Follower 毗连 Leader ，将最大的 zxid 发送给 Leader 。
  
• 3、Leader 根据 Follower 的 zxid 确定同步点。
  
• 4、完成同步后关照 Follower 已经成为 update 状态。
  
• 5、Follower 收到 update 消息后，又可以重新继续 Client 的哀求举行服务了。
  

固然，同步流程并不是像上述形貌的这么简朴，详细的，照旧得看看 《Zookeeper Leader 和 Learner 的数据同步》 。
估计大多数胖友，学习 Zookeeper 的过程，是由于利用 Dubbo 时，须要利用到 Zookeeper 作为注册中央，然后快速搭建了下。然后，断断续续看了下 Zookeeper 的文章。🙂 就当是复习。面临的时间，比力重点的几个标题是：

• Zookeeper 的推选过程？
  
• Zookeeper 怎样提供分布式锁？
  
• Zookeeper 的一些应用场景？
  

参考与保举如下文章：

• 《Zookeeper 口试题》
  
• 《假如有人问你 ZooKeeper 是什么，就把这篇文章发给他》