ZooKeeper集群与Leader选举

说说你对ZooKeeper集群与Leader选举的理解？

 

 ZooKeeper是一个开源分布式协调服务、分布式数据一致性解决方案。可基于ZooKeeper实现命名服务、集群管理、Master选举、分布式锁等功能。

  高可用  

为了保证ZooKeeper的可用性，在生产环境中咱们使用ZooKeeper集群模式对外提供服务，而且集群规模至少由3个ZooKeeper节点组成。

  集群至少由3个节点组成  

ZooKeeper其实2个节点也能够组成集群并对外提供服务，但咱们使用集群主要目的是为了高可用。若是2个节点组成集群，其中1个节点挂了，另外ZooKeeper节点不能正常对外提供服务。所以也失去了集群的意义。

若是3个节点组成集群，其中1个节点挂掉后，根据ZooKeeper的Leader选举机制是能够从另外2个节点选出一个做为Leader的，集群能够继续对外提供服务。

  并不是节点越多越好  

• 节点越多，使用的资源越多

• 节点越多，ZooKeeper节点间花费的通信成本越高，节点间互连的Socket也越多。影响ZooKeeper集群事务处理

• 节点越多，形成脑裂的可能性越大

  集群规模为奇数  

集群规模除了考虑自身成本和资源外还要结合ZooKeeper特性考虑：

• 节省资源

  3节点集群和4节点集群，咱们选择使用3节点集群；5节点集群和6节点集群，咱们选择使用5节点集群。以此类推。由于生产环境为了保证高可用，3节点集群最多只容许挂1台，4节点集群最多也只容许挂1台(过半原则中解释了缘由)。同理5节点集群最多容许挂2台，6节点集群最多也只容许挂2台。

  出于对资源节省的考虑，咱们应该使用奇数节点来知足相同的高可用性。

• 集群可用性

  当集群中节点间网络通信出现问题时奇数和偶数对集群的影响

  集群配置  

ZooKeeper集群配置至少须要2处变动：

一、增长集群配置

在{ZK_HOME}/conf/zoo.cfg中增长集群的配置，结构以server.id=ip:port1:port2为标准。

好比下面配置文件中表示由3个ZooKeeper组成的集群：

server.1=localhost:2881:3881
server.2=localhost:2882:3882
server.3=localhost:2883:3883

 

 

二、配置节点id

zoo.cfg中配置集群时须要指定server.id，这个id须要在dataDir（zoo.cfg中配置）指定的目录中建立myid文件，文件内容就是当前ZooKeeper节点的id。

  集群角色  

ZooKeeper没有使用Master/Slave的概念，而是将集群中的节点分为了3类角色：

• Leader

  在一个ZooKeeper集群中，只能存在一个Leader，这个Leader是集群中事务请求惟一的调度者和处理者，所谓事务请求是指会改变集群状态的请求；Leader根据事务ID能够保证事务处理的顺序性。

  若是一个集群中存在多个Leader，这种现象称为「脑裂」。试想一下，一个集群中存在多个Leader会产生什么影响？

  至关于本来一个大集群，裂出多个小集群，他们之间的数据是不会相互同步的。「脑裂」后集群中的数据会变得很是混乱。

• Follower

  Follower角色的ZooKeeper服务只能处理非事务请求；若是接收到客户端事务请求会将请求转发给Leader服务器；参与Leader选举；参与Leader事务处理投票处理。

  Follower发现集群中Leader不可用时会变动自身状态，并发起Leader选举投票，最终集群中的某个Follower会被选为Leader。

• Observer

  Observer与Follower很像，能够处理非事务请求；将事务请求转发给Leader服务器。

  与Follower不一样的是，Observer不会参与Leader选举；不会参与Leader事务处理投票。

  Observer用于不影响集群事务处理能力的前提下提高集群的非事务处理能力。

  Leader选举  

Leader在集群中是很是重要的一个角色，负责了整个事务的处理和调度，保证分布式数据一致性的关键所在。既然Leader在ZooKeeper集群中这么重要因此必定要保证集群在任什么时候候都有且仅有一个Leader存在。

若是集群中Leader不可用了，须要有一个机制来保证能从集群中找出一个最优的服务晋升为Leader继续处理事务和调度等一系列职责。这个过程称为Leader选举。

  选举机制  

ZooKeeper选举Leader依赖下列原则并遵循优先顺序：

一、选举投票必须在同一轮次中进行

若是Follower服务选举轮次不一样，不会采纳投票。

二、数据最新的节点优先成为Leader

数据的新旧使用事务ID断定，事务ID越大认为节点数据约接近Leader的数据，天然应该成为Leader。

三、比较server.id，id值大的优先成为Leader

若是每一个参与竞选节点事务ID同样，再使用server.id作比较。server.id是节点在集群中惟一的id，myid文件中配置。

不论是在集群启动时选举Leader仍是集群运行中从新选举Leader。集群中每一个Follower角色服务都是以上面的条件做为基础推选出合适的Leader，一旦出现某个节点被过半推选，那么该节点晋升为Leader。

  过半原则  

ZooKeeper集群会有不少类型投票。Leader选举投票；事务提议投票；这些投票依赖过半原则。就是说ZooKeeper认为投票结果超过了集群总数的一半，即可以安全的处理后续事务。

• 事务提议投票

  假设有3个节点组成ZooKeeper集群，客户端请求添加一个节点。Leader接到该事务请求后给全部Follower发起「建立节点」的提议投票。若是Leader收到了超过集群一半数量的反馈，继续给全部Follower发起commit。此时Leader认为集群过半了，就算本身挂了集群也是安全可靠的。

• Leader选举投票

  假设有3个节点组成ZooKeeper集群，这时Leader挂了，须要投票选举Leader。当相同投票结果过半后Leader选出。

• 集群可用节点

  ZooKeeper集群中每一个节点有本身的角色，对于集群可用性来讲必须知足过半原则。这个过半是指Leader角色 + Follower角色可用数大于集群中Leader角色 + Follower角色总数。
  假设有5个节点组成ZooKeeper集群，一个Leader、两个Follower、两个Observer。当挂掉两个Follower或挂掉一个Leader和一个Follower时集群将不可用。由于Observer角色不参与任何形式的投票。

所谓过半原则算法是说票数 > 集群总节点数/2。其中集群总节点数/2的计算结果会向下取整。

在ZooKeeper源代码QuorumMaj.java中实现了这个算法。下面代码片断有所缩减。

public boolean containsQuorum(HashSet<Long> set) {
  /** n是指集群总数 */
  int half = n / 2;
  return (set.size() > half);
}

回过头咱们看一下奇数和偶数集群在Leader选举的结果

因此3节点和4节点组成的集群在ZooKeeper过半原则下都最多只能挂1节点，可是4比3要多浪费一个节点资源。

  场景实战  

咱们以两个场景来了解集群不可用时Leader从新选举的过程。

  3节点集群重选Leader  

假设有3节点组成的集群，分别是server.1（Follower）、server.2（Leader）、server.3（Follower）。此时server.2不可用了。集群会产生如下变化：

一、集群不可用

由于Leader挂了，集群不可用于事务请求了。

二、状态变动

全部Follower节点变动自身状态为LOOKING，而且变动自身投票。投票内容就是本身节点的事务ID和server.id。咱们以(事务ID, server.id)表示。

假设server.1的事务id是10，变动的自身投票就是（10, 1）；server.3的事务id是8，变动的自身投票就是（8, 3）。

三、首轮投票

将变动的投票发给集群中全部的Follower节点。server.1将（10, 1）发给集群中全部Follower，包括它本身。server.3也同样，将（8, 3）发给全部Follower。

因此server.1将收到（10, 1）和（8, 3）两个投票，server.3将收到（8, 3）和（10, 1）两个投票。

四、投票PK

每一个Follower节点除了发起投票外，还接其余Follower发来的投票，并与本身的投票PK(比较两个提议的事务ID以及server.id)，PK结果决定是否要变动自身状态并再次投票。

对于server.1来讲收到（10, 1）和（8, 3）两个投票，与本身变动的投票比较后没有一个比自身投票（10, 1）要大的，因此server.1维持自身投票不变。

对于server.3来讲收到（10, 1）和（8, 3）两个投票，与自身变动的投票比较后认为server.1发来的投票要比自身的投票大，因此server.3会变动自身投票并将变动后的投票发给集群中全部Follower。

五、第二轮投票

server.3将自身投票变动为（10, 1）后再次将投票发给集群中全部Follower。

对于server.1来讲在第二轮收到了（10, 1）投票，server.1通过PK后继续维持不变。

对于server.3来讲在第二轮收到了（10, 1）投票，由于server.3自身已变动为（10, 3）投票，因此本次也维持不变。

此时server.1和server.3在投票上达成一致。

六、投票接收桶

节点接收的投票存储在一个接收桶里，每一个Follower的投票结果在桶内只记录一次。ZooKeeper源码中接收桶用Map实现。

下面代码片断是ZooKeeper定义的接收桶，以及向桶内写入数据。Map.Key是Long类型，用来存储投票来源节点的server.id，Vote则是对应节点的投票信息。节点收到投票后会更新这个接收桶，也就是说桶里存储了全部Follower节点的投票而且仅存最后一次的投票结果。

HashMap<Long, Vote> recvset = new HashMap<Long, Vote>();
recvset.put(n.sid, new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch));

七、统计投票

接收到投票后每次都会尝试统计投票，投票统计过半后选举成功。

投票统计的数据来源于投票接收桶里的投票数据，咱们从头描述这个场景，来看一下接收桶里的数据变化状况。

server.2挂了后，server.1和server.3发起第一轮投票。

server.1接收到来自server.1的（10, 1）投票和来自server.3的（8, 3）投票。

server.3一样接收到来自server.1的（10, 1）投票和来自server.3的（8, 3）投票。此时server.1和server.3接收桶里的数据是这样的：

server.3通过PK后认为server.1的选票比本身要大，因此变动了本身的投票并从新发起投票。

server.1收到了来自server.3的（10, 1）投票;server.3收到了来自sever.3的（10, 1）投票。此时server.1和server.3接收桶里的数据变成了这样：

基于ZooKeeper过半原则：桶内投票选举server.1做为Leader出现2次，知足了过半 2 > 3/2 即 2>1。

最后sever.1节点晋升为Leader，server.3变动为Follower。

 集群扩容Leader启动时机 

ZooKeeper集群扩容须要在zoo.cfg配置文件中加入新节点。扩容流程在ZooKeeper扩容中介绍。这里咱们以3节点扩容到5节点时，Leader启动时机作一个讨论。

假设目前有3个节点组成集群，分别是server.1（Follower）、server.2（Leader）、server.3（Follower），假设集群中节点事务ID相同。配置文件以下。

server.1=localhost:2881:3881
server.2=localhost:2882:3882
server.3=localhost:2883:3883

一、新节点加入集群

集群中新增server.4和server.5两个节点，首先修改server.4和server.5的zoo.cfg配置并启动。节点4和5在启动后会变动自身投票状态，发起一轮Leader选举投票。server.一、server.二、server.3收到投票后因为集群中已有选定Leader，因此会直接反馈server.4和server.5投票结果：server.2是Leader。server.4和server.5收到投票后基于过半原则认定server.2是Leader，自身便切换为Follower。

#节点server.一、server.二、server.3配置
server.1=localhost:2881:3881
server.2=localhost:2882:3882
server.3=localhost:2883:3883

#节点server.四、server.5配置
server.1=localhost:2881:3881
server.2=localhost:2882:3882
server.3=localhost:2883:3883
server.4=localhost:2884:3884
server.5=localhost:2885:3885

二、中止Leader

server.4和server.5的加入须要修改集群server.一、server.二、server.3的zoo.cfg配置并重启。可是Leader节点什么时候重启是有讲究的，由于Leader重启会致使集群中Follower发起Leader从新选举。在server.4和server.5两个新节点正常加入后，集群不会由于新节点加入变动Leader，因此目前server.2依然是Leader。

咱们以一个错误的顺序启动，看一下集群会发生什么样的变化。修改server.2zoo.cfg配置文件，增长server.4和server.5的配置并中止server.2服务。中止server.2后，Leader不存在了，集群中全部Follower会发起投票。当server.1和server.3发起投票时并不会将投票发给server.4和server.5，由于在server.1和server.3的集群配置中不包含server.4和server.5节点。相反，server.4和server.5会把选票发给集群中全部节点。也就是说对于server.1和server.3他们认为集群中只有3个节点。对于server.4和server.5他们认为集群中有5个节点。

根据过半原则，server.1和server.3很快会选出一个新Leader，咱们这里假设server.3晋级成为了新Leader。可是咱们没有启动server.2的状况下，由于投票不知足过半原则，server.4和server.5会一直作投票选举Leader的动做。截止到如今集群中节点状态是这样的：

三、启动Leader

如今，咱们启动server.2。由于server.2zoo.cfg已是server.1到serverv.5的全量配置，在server.2启动后会发起选举投票，同时serverv.4和serverv.5也在不断的发起选举投票。当server.2的选举轮次和serverv.4与serverv.5选举轮次对齐后，最终server.2会变动本身的状态，认定server.5是Leaader。

意想不到的事情发生了，出现两个Leader：

ZooKeeper集群扩容时，若是Leader节点最后启动就能够避免这类问题发生，由于在Leader节点重启前，全部的Follower节点zoo.cfg配置已是相同的，他们基于同一个集群配置两两互联，作投票选举。

架构师小秘圈

汇集20万架构师的小圈子