长按二维码关注
大数据领域必关注的公众号
题目描述：
简述一下Zookeeper的Leader选举机制。
分析与解答：
Leader选举是保证分布式数据一致性的关键所在，在Zookeeper3.4.x之后的版本中，只保留了FastLeaderElection选举算法来选举Leader。当Zookeeper集群中的一台服务器出现以下两种情况之一时，需要进入Leader选举。
（1）Zookeeper集群初始启动。
（2）Zookeeper集群中Leader节点失联或者宕机。
为了理解Zookeeper的Leader选举过程，我们先介绍一下Zookeeper节点的几种状态。
（1）LOOKING：表示不确定Leader的“寻找”状态，即当前节点认为集群中没有Leader，进而发起选举。
（2）LEADING：表示“领导”状态，即当前节点就是Leader，并维护与Follower和Observer的通信。
（3）FOLLOWER：“跟随”状态，即当前阶段是Follower，且正在保持与Leader的通信。
（4）OBSERVING：“观察”状态，即当前阶段是Observer，且正在保持与Leader的通信，但是不参与Leader选举。
Zookeeper Leader选举过程中包含如下核心投票信息。
（1）ZXID：表示事务ID。ZXID是一个事务ID，用来标识一次服务器状态的表更。在某一时刻，集群中每台机器的ZXID值不一定完全一致，这跟Zookeeper服务器对于客户端更新请求的处理逻辑有关。
（2）SID：表示服务器ID。用来唯一标识一台Zookeeper集群中的机器，每台机器不能重复，与Zookeeper配置文件中的myid文件内容一致。
Zookeeper Leader选举的投票比较规则如下。
（1）优先比较ZXID，ZXID大的胜出，否则进行第2步。
（2）然后再比较SID，SID大的胜出。
（3）当某台服务器获得超过一半的投票，它会被选举为Leader。
Zookeeper集群初始启动时的Leader选举
假设Zookeeper集群一共有三个节点，分别为hadoop01、hadoop02和hadoop03。
（1）当第一台服务器hadoop01启动时，发起一次选举。hadoop01投自己一票，获得投票结果为(1,0)。此时hadoop01只有1票，没有超过半数以上的票数（2票），本轮选举无法完成，hadoop01的状态保持为LOOKING。
（2）当第二台服务器hadoop02启动时，再发起一次选举。hadoop01和hadoop02分别投自己一票并交换选票信息，获得投票结果为(1,0) (2,0)。此时hadoop01发现hadoop02的SID比自己此轮投票推荐的SID要大，根据投票规则更改选票为推荐hadoop02。此时hadoop01得票数为0，hadoop02得票数为2，投票结果超过半数，hadoop02当选Leader。hadoop01更改状态为FOLLOWING，hadoop02更改状态为LEADING。
（3）当第三台服务器hadoop03启动时，发起一次选举。此时hadoop01和hadoop02节点已经不是LOOKING状态，不会更改选票信息。所有节点交换选票结果：hadoop02获得2票，hadoop03获得1票。此时hadoop03节点服从多数选举结果，更改选票信息为hadoop02，并更改状态为FOLLOWING。
Zookeeper集群运行时的Leader选举
假定Zookeeper集群由hadoop01、hadoop02、hadoop03、hadoop04和hadoop05组成，SID分别为1、2、3、4、5，ZXID分别为9、9、9、8、8，并且此时hadoop02是Leader，某一时刻，hadoop01、hadoop02所在机器出现故障，因此集群开始新的Leader选举。
（1）由于hadoop02节点为Leader，当hadoop01、hadoop02所在机器出现故障，Zookeeper服务器其他节点的状态变更为LOOKING，然后开始进入Leader选举过程。
（2）Zookeeper每个Server会分别投自己一票并交换选票信息，hadoop03投票为(3,9)，hadoop04投票为(4,8)，hadoop05投票为(5,8)。
（3）Zookeeper集群各投票节点接受的投票结果为(3,9) (4,8) (5,8)，然后检查本轮投票的有效性。
（4）根据投票规则，ZXID为9的值最大，hadoop03节点胜出，hadoop04和hadoop05更改选票为推荐hadoop03。
（5）每次投票之后，Zookeeper服务器都会统计投票信息，判断是否已经有超过半数的节点收到相同的投票信息。此时hadoop03得票数为3，投票结果超过半数（3票），hadoop03当选为Leader。
（6）一旦确定了Leader，Zookeeper每台服务器就会更新自己的状态。hadoop03节点状态更改为LEADING，hadoop04和hadoop05状态更改为FOLLOWING。
在Zookeeper集群运行过程中，假如出现故障的机器不是Leader节点，那么Zookeeper集群也就无需进行Leader选举。
题目描述：
讲一讲什么是CAP法则？Zookeeper符合哪种CAP法则？
分析与解答：
1.什么是CAP理论
我们知道要保证ZooKeeper服务的高可用性，就需要采用分布式模式来实现数据冗余，为了实现数据冗余会带来数据一致性问题，而一致性问题又会带来集群性能问题，由此陷入了僵局。这里就涉及到著名的CAP理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
2.C、A、P的含义
（1）Consistency（一致性）
对于客户端的每次读操作，要么读到的是最新的数据，要么读取失败。换句话说，一致性是站在分布式系统的角度，对访问本系统的客户端的一种承诺：要么我给您返回一个错误，要么我给你返回绝对一致的最新数据，不难看出，其强调的是数据正确。
（3）Availability（可用性）
任何客户端的请求都能得到响应数据，不会出现响应错误。换句话说，可用性是站在分布式系统的角度，对访问本系统的客户端的另一种承诺：我一定会给您返回数据，不会给你返回错误，但不保证数据最新，强调的是不出错。
（4）Partition Tolerance（分区容错性）
由于分布式系统通过网络进行通信，网络是不可靠的。当任意数量的消息丢失或延迟到达时，系统仍会继续提供服务，不会挂掉。换句话说，分区容忍性是站在分布式系统的角度，对访问本系统的客户端的再一种承诺：我会一直运行，不管我的内部出现何种数据同步问题，强调的是不挂掉。
3.如何理解CAP
（1）在一个分布式系统里面，节点组成的网络本来应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就散布在这些不连通的区域中，这就叫分区。
（2）当你的一个数据项只在集群中的一个节点中保存，那么当集群分区出现后，与这个节点不连通的其他节点就访问不到这个数据项，此时的分区是无法容忍的。
（3）提高分区容忍性的办法就是将一个数据项复制到多个节点上，那么当集群出现分区之后，这个数据项就会存储到集群各个区中，那么容忍性就提高了。
（4）然而，要把一个节点中的数据项复制到其他节点，就会带来数据一致性的问题，通俗的讲就是多个节点上面的数据可能是不一致的。为了保证数据的一致性，每次写操作都要等待全部节点写成功，等待时间过长就会带来集群的可用性问题。
总的来说，数据存储的节点越多，分区容忍性越高，但数据需要同步的节点就越多，那么
数据一致性就越难保证。为了保证数据一致性，数据更新到所有节点所需要的时间就越长，集群的可用性就会降低。
4.Zookeeper符合哪种CAP法则
ZooKeeper是分布式协调服务，它的职责是保证数据在所有服务节点之间保持同步、一致，所以ZooKeeper遵循的是CP原则，从而牺牲了可用性。换句话说客户端任何时刻对ZooKeeper的访问请求都能得到一致的数据结果，同时系统对网络分割具备容错性。
但Zookeeper不能保证每次服务请求的可用性，因为当Zookeeper进行Leader选举时，所有节点状态为LOOKING，此时集群不能对外提供服务，所以Zookeeper不满足可用性。
题目描述：
谈一谈ZAB协议在Zookeeper中的作用。
分析与解答：
1.ZAB定义
ZAB协议的全称为Zookeeper Atomic Broadcast（Zookeeper原子广播），通过ZAB协议来保证分布式事务的最终一致性。
ZAB是专门为Zookeeper设计的支持奔溃恢复的原子广播协议，在Zookeeper中主要依赖ZAB协议实现数据一致性。基于ZAB协议，Zookeeper实现了一种主备（Leader与Follower）的系统架构保证集群中各个副本之间的数据一致性。
2.ZAB协议的核心
在Zookeeper集群中只有一个Leader，并且只有 Leader 可以处理外部客户端的事务请求，并将其转换成一个事务Proposal（写操作），然后 Leader服务器再将事务 Proposal 操作的数据同步到所有Follower（数据广播/数据复制）。
Zookeeper采用ZAB协议的核心就是只要有一台服务器提交了事务Proposal，就要确保所有服务器最终都能正确提交事务Proposal，这也是Zookeeper在CAP法则中实现最终一致性的体现。
3.ZAB协议的模式
ZAB协议有两种模式：一种是消息广播模式，另一种是崩溃恢复模式 。
（1）消息广播模式
在 Zookeeper 集群中，数据副本的传递策略就是采用消息广播模式，Zookeeper 中的数据副本同步方式与2PC（两阶段提交）方式相似但却不同，2PC是要求协调者必须等待所有参与者全部反馈ACK确认消息后，再发送commit 消息。它要求所有参与者要么全成功要么全失败，2PC方式会产生严重的阻塞问题。
而在Zookeeper中，Leader等待Follower的ACK反馈消息是指：只要半数以上的Follower成功反馈消息给Leader即可，Leader不需要收到全部Follower 的反馈消息。
Zookeeper中广播消息的步骤如下：
（1）客户端发起一个写操作请求。
（2）Leader 服务器处理客户端请求后将请求转换为 Proposal，同时为每个 Proposal 分配一个全局唯一 ID，即 ZXID。
（3）Leader 服务器与每个 Follower 之间都有一个队列，Leader 将消息发送到该队列。
（4）Follower 机器从队列中取出消息处理完（写入本地事务日志中）后，向 Leader 服务器发送 ACK 确认消息。
（5）Leader 服务器收到半数以上的 Follower 的 ACK 后，即认为可以发送 Commit消息提交事务。
（6）Leader 向所有的 Follower 服务器发送 Commit 消息。
（2）奔溃恢复模式
在Zookeeper集群中，为保证所有进程能够有序的顺序执行，只能由Leader服务器接受写请求，即使Follower服务器先接受到了客户端的请求，也会转发给Leader服务器进行处理。如果Leader服务器发生崩溃，则ZAB协议要求Zookeeper集群进行Leader选举和数据同步。
ZAB协议崩溃恢复模式要求满足如下2个要求：
1）确保已经被Leader提交的Proposal，必须最终被所有的Follower服务器接受。
2）确保丢弃已经被Leader发出的但是没有被提交的Proposal。
根据这2个要求，新选举出来的Leader不能包含未提交的Proposal，同时拥有最高的ZXID。这样做的好处就是可以避免了Leader服务器检查Proposal的提交和丢弃工作。
Leader服务器发生崩溃时分为如下两种场景：
1）Leader在已经提交Proposal但未commit之前崩溃，则经过崩溃恢复之后，新选举的Leader一定不能是刚才的Leader，因为这个Leader存在未commit的Proposal。
2）Leader在提交commit消息之后崩溃，即commit消息已经发送到队列中。进入崩溃恢复模式之后，在参与选举的Follower服务器中，所有Follower节点已经消费了队列中所有的commit消息，即此类Follower节点将会被选举为最新的Leader。Leader选举出来之后，剩下动作就是数据同步过程。
当Leader宕机后，ZAB就进入了崩溃恢复模式，这个过程包含Leader选举和数据同步。Leader选举过程就不再赘述，这里重点介绍数据（状态）同步过程。新Leader选举成功之后，Leader会将自身提交Proposal的最大事物ZXID发送给其他的Follower节点。Follower节点会根据Leader的消息进行回退或者数据同步操作，从而保证集群中所有节点的数据副本一致。
题目描述：
生产环境中，Zookeeper集群节点数为多少合适？为什么ZooKeeper集群节点个数是奇数而不是偶数。
分析与解答：
1.Zookeeper集群节点个数
一般Zookeeper是由2n+1个节点组成的集群服务，只要Zookeeper集群中超过一半以上的机器能够正常工作，那么整个Zookeeper集群就能对外提供服务。在生产环境中，Zookeeper集群节点个数不宜过多，否则整个Zookeeper集群性能比较差，比如客户端往Zookeeper集群写数据，只有超过一半的节点写成功，Zookeeper才认为是写成功，那么节点数越多等待写成功的时间就越长，Zookeeper集群性能就越差。
所以根据工作经验值，大数据集群如果在100节点以下，Zookeeper集群选择3个节点即可；大数据集群如果在100~500节点之间，Zookeeper集群选择5个节点即可；大数据集群如果在1000节点以上，Zookeeper集群选择7个节点即可。
2.Zookeeper集群节点个数是奇数还是偶数
首先需要明确的是Zookeeper集群节点数可以为奇数也可以为偶数，但我们一般选择奇数个节点。因为Zookeeper集群只有超过半数以上节点正常工作，Zookeeper才能对外提供服务。那么当Zookeeper集群节点数为5时，最多只允许2个节点宕机。当Zookeeper集群节点数为6时，同样最多只允许2个节点宕机。由于Zookeeper集群节点数为5或者6，最终允许宕机的节点个数是一样的，所以出于节约集群资源的角度考虑，我们一般选择奇数个节点组建Zookeeper集群。
题目描述：
如何理解Zookeeper的监听器原理。
分析与解答：
Zookeeper的监听器原理如图1-1所示。
图1-1 Zookeeper 的监听器原理
Zookeeper的监听机制可以分为以下几个过程。
1.客户端创建zkClient，此时会创建两个线程，一个线程负责网络连接通信（connect），一个负责监听（Listener）。
2.zkClient通过Connect线程连接服务端，并监听Znode节点。
3.Zookeeper将注册的监听事件添加到监听器列表中，表示Znode节点被客户端监听了。
4.一旦Znode节点数据发生变化，Zookeeper服务端就会将消息发生给Listener线程。
5.Listener线程内部调用process()方法，进行相应的逻辑处理。
题目描述：
ZooKeeper如何保证事务的顺序一致性。
分析与解答：
Zookeeper采用了全局递增的事务ID来标识，所有的 Proposal（提议）在被提出的时候都加上了ZXID。ZXID实际上是一个 64位的数字，高32位是epoch用来标识Leader周期，低32位是Zookeeper发起的Proposal的次数。
如果Zookeeper集群发起新的Proposal，ZXID的高32位epoch编号保持不变，ZXID的低32位会递增计数。如果Zookeeper集群有新的Leader被选举出来，ZXID的高32位epoch编号会自增加1，ZXID的低32位重置为0，这就保证了Zookeeper每次选举出Leader之后，ZXID是唯一且递增的。
题目描述：
ZooKeeper集群节点宕机之后内部如何处理。
分析与解答：
Zookeeper集群节点最低配置为3台服务器，假设现在有一个3节点的Zookeeper集群，只要超过半数节点（2个节点）正常工作，Zookeeper集群就能正常对外提供服务。
当Zookeeper集群挂掉2个节点，此时集群剩余1个节点，集群无法对外提供服务。
当Zookeeper集群挂掉1个节点，此时集群还有2个节点正常，集群仍然可以对外提供服务。Zookeeper集群宕机1个节点可以分为两种情况。
（1）如果是Follower节点宕机，Zookeeper集群无需Leader选举，数据也不会丢失，仍然可以对外提供服务。
（2）如果是Leader节点宕机，Zookeeper集群需要进行Leader选举，然后集群进行数据同步，最后仍然可以对外提供服务。
题目描述：
ZooKeeper集群是否支持动态添加机器
分析与解答：
本题目其实就是问Zookeeper是否支持水平扩容，Zookeeper在这个方面支持不是太好，主要通过两种方式实现水平扩容。
（1）全部重启Zookeeper服务：首先关闭所有Zookeeper服务，然后分别修改Zookeeper配置并重启服务。
（2）逐个重启Zookeeper服务：在Zookeeper过半节点存活即可用的原则下，逐个修改Zookeeper配置并重启服务，这样不会影响整个集群对外提供服务。
从3.5版本开始，Zookeeper支持节点动态扩缩容。
题目描述：
如何迁移大数据平台中的ZooKeeper集群？
分析与解答：
ZooKeeper是一种分布式协调服务，它的职责是保证数据在所有服务节点之间保持同步、一致，也就是说Zookeeper集群中每台服务器的数据都是一致了，我们可以利用这一特性来迁移Zookeeper集群，具体操作步骤如下。
（1）首先对原Zookeeper集群进行水平扩容，将新Zookeeper集群节点添加到原Zookeeper集群中。
（2）然后原Zookeeper集群为了保证数据的一致性，最终会将数据同步到新增Zookeeper节点中，这样新增Zookeeper节点拥有原Zookeeper集群完整的元数据。
（3）最后逐步下线原Zookeeper集群节点，即可实现Zookeeper集群的数据迁移。
完
