zookeeper选举（zookeeper选举协议）

本篇文章给大家谈谈zookeeper选举，以及zookeeper选举协议对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、[ZooKeeper之五] 使用 ZooKeeper 实现主-从模式
• 2、Zookeeper选主流程
• 3、ZooKeeper - 常见问题
• 4、zookeeper Leader的选举过程
• 5、Zookeeper之领导者选举算法源码分析
• 6、大数据Hadoop之ZooKeeper认识

[ZooKeeper之五] 使用 ZooKeeper 实现主-从模式

  在 [ZooKeeper之一] ZooKeeper简介 中，介绍了主-从架构，再简单回顾下，首先主-从架构中要有一个主，Master 接受客户端提交任务，同时监测每个 worker 的状态，并将任务分配给 worker 执行，worker 负责执行 Master 分配的任务并返回执行结果，Master 收到执行结果时将其返回给客户端。

（1）主节点选举和故障转移

  主-从模式，首先要有一个主节点，由多个备用节点选举产生，选出主节点后，没当选主节点的备用节点就会设置一个对主节点的监听器，当主节点发生故障时，所有备用节点都会收到通知，并扮拦重新选举出新的主节点。

（2）从节点的动态检测

  从节点负责执行主节点分配的任务，为了让主节点能感知到从节点的存在，需要在 ZooKeeper 的某一指定路径下（比如 /workers ）创建一个代表工作伏源节点对应的 znode，当某个从节点发生故障时，该 znode 应该被自动删除，所以使用临时节点来创建对应的znode。

（3）客户端和任务

  客户端向系统中提交任务，并等待系统返回执行结果。同样地，我们需要在 ZooKeeper 的某一指定路径下（比如 /tasks ）创建znode，每个znode表示一个任务，为了防止系统故障导致提交的任务丢失，所以表示任务的 znode 应该用持久节点。

  接下来，启动好 ZooKeeper 服务端缺缺态和客户端工具，实现它！

  ZooKeeper 通过多个节点进行同时尝试创建某个znode（比如 /lock ），可以实现一个简单的分布式锁，哪个节点进程成功创建了 /lock ，就说它抢到了锁。锁原语同样可用于确定主节点，假如创建的znode为 /master ，为了防止抢到锁之后主节点挂掉之后，无法重新竞争出新的主节点，需要将 /master 以临时节点的形式创建，从锁的角度看，是先释放锁资源才能让备用节点们去抢锁。

  这里启动多个 zkcli 终端来表示多个不同抢锁的节点

  当一个节点去抢锁竞争主节点时，会遇到两种情况：一种是成功抢到锁；另一种是抢锁失败，提示节点已经存在，这时候需要去设置对应的监听器，这样当锁被释放时，可以收到通知重新抢锁。下面分别用节点1、节点2来表示这两种情况：

  现在关掉节点1的终端，模拟主节点故障的情况，等过了超时时间，可以看到节点2收到通知

  这时候备用节点有机会抢到锁，由于这里只有一个备用节点没人抢，所以成功转正

  主节点需要先创建约定好的目录来放工作节点、任务以及任务分配，并且需要动态监控工作节点和任务的变化，所以还需要设置工作节点目录和任务目录的监听器

  首先需要在 /workers 目录下创建一个子节点，然后从节点需要在 /assign 下创建一个子节点来接收主节点分配的任务，由于子节点需要动态检测分配任务的变化，所以还需要对分配任务目录设置监听器。

  客户端通过在 /tasks 下创建znode来表示一个任务

Zookeeper选主流程

在Zookeeper集群中，主要族山分为三者角色，而每一个节点同时只能扮演一种角色，这三种角色分别是：

每个Server在工作过程中有四种状态：

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实空基现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是 恢复模式（选主） 和 广播模式（同步） 。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。leader选举是保证分布式数据一致性的关键。

当zk集群中的一台服务器出现以下两种情况之一时，就会开始leader选举。

而当一台机器进入leader选举流程时，当前集群也可能处于以下两种状态。

首先第一种情况，通常是集群中某一台机器启动比较晚，在它启动之前，集群已经正常工作，即已经存在一台leader服务器。当该机器试图去选举leader时，会被告知当前服务器的leader信息，它仅仅需要和leader机器建立连接，并进行状态同步即可。

下面重点看第二种情况，即集群中leader不存在的情况下如何进行leader选举。

投票信息中包含两个最基本的信息。

集群中的每台机器发出自己的投票后，也会接受来自集群中其他机器的投票。每台机器都会根据一定的规则，来处理收到的其他机器的投票，以此来决定是否需要变更自己的投票。

规则如下：

假设当前集群中有5台兆亏中机器组成。sid分别为1，2，3，4，5。zxid分别为9，9，9，8，8，并且此时sid为2的机器是leader。某一时刻，1和2的服务器挂掉了，集群开始进行选主。

[img]

ZooKeeper - 常见问题

Zookeeper是一个分布式数据管理与协调服务，目标是可以提供高性能、高可用和顺序访问控制的能力，同时也是为了解决分布式环境下数据一致性的问题。

在一致性协议方面，注重CP。

首先，Zookeeper集群中有几个关键的概念，Leader、Follower和Observer，Zookeeper中通常只有Leader节点可以写入，Follower和Observer都只是负责读，但是Follower会参与节点的选举和过半写成功，Observer则不会，他只是单纯的提供读取数据的功能。

通常这样设置的话，是为了避免太多的从节点参与过半写的过程，导致影响性能，这样Zookeeper只要使用一个几台机器的小集群就可以实现高性能了，如果要横向扩展的话，只需要增加Observer节点即可。

ZooKeeper建议集群节点个数为奇数，只要超过一半的机器能够正常提供服务，那么悉明灶整个集群都是可用的状态。

Zookeeper中数据存储于内存之中，这个数据节点就叫做Znode，他是一个树形结构，比如/a/b/c类似。

而Znode又分为持久节点、临时节点、顺序节点三大类。

持久节点是指只要被创建，除非主动移除，否则都应该一直保存在Zookeeper中。

临时节点不同的是，他的生命周期和客户端Session会话一样，会话失效，那么临时节点就会被移除。

还有就是临时顺序节点和持久顺序节点，除了基本的特性之外，子节点的名称还具有有序性。

会话自然就是指Zookeeper客户端和服务端之间的通信，他们使用TCP长连接的方式保持通信，通常，肯定会有心跳检测的机制，同时他可以接受来自服务器的Watch事件通知。

用户可以在指定的节点上注册Wather，这样在事件触发的时候，客户端就会收到来自服务端的通知。

Zookeeper使用ACL来进行权限的控制，包含以下5种：

CREATE，创建子节点权限

DELETE，删除子节点权限

READ，获取节点数据和子节点列表权限

WRITE，更新节点权限

ADMIN，设置节点ACL权限

所以，ZooKeeper通过集群的方式来做到高可用，通过内存数据节点Znode来达到高性能，但是存储的数据量不能太大，通常适用于读多写少的场景。

Zookeeper可以提供分布式数据的发布/订阅功能，依赖的就是Wather监听机制。

客户端可以向服务端注册Wather监听，服务端的指定事件触发之后，就会向客户端发送一个事件通知。

他有几个特性：

Zookeeper通过ZAB原子广播协议来实现数据的最终顺序一致性，他是一个类似2PC两阶段提交的过程。

由于Zookeeper只有Leader节点可以写入数据，如果是其他节点收到写入数据的请求，则会将之转发给Leader节点。

主要流程如下：

Leader收到请求之后，将它转换为一个proposal提议，并且为每个提议分配一个全局唯一递增的事务ID：zxid，然后把提议放入到一个FIFO的队列中，按照FIFO的策略发送给所有的Follower

Follower收到提议之后，以事务日志的形式写入到本地磁盘中，写入成功后返回ACK给Leader

Leader在收到超过半数的Follower的ACK之后，即睁扮可认为数据写入成功，就会发送commit命令给Follower告诉他们可以提交proposal了

ZAB包含两种基本模式，崩溃恢复和消息广播。

整个集群服务在启动、网络中断或者重启等异常情况的时候，首先会进入到崩溃恢复状态，此时会通过选举产生Leader节点，当集群过半槐竖的节点都和Leader状态同步之后，ZAB就会退出恢复模式。之后，就会进入消息广播的模式。

Leader的选举可以分为两个方面，同时选举主要包含事务zxid和myid，节点主要包含3个状态

首先，每个节点都会对自己进行投票，然后把投票信息广播给集群中的其他节点

节点接收到其他节点的投票信息，然后和自己的投票进行比较，首先zxid较大的优先，如果zxid相同那么则会去选择myid更大者，此时大家都是LOOKING的状态

投票完成之后，开始统计投票信息，如果集群中过半的机器都选择了某个节点机器作为leader，那么选举结束

最后，更新各个节点的状态，leader改为LEADING状态，follower改为FOLLOWING状态

如果开始选举出来的leader节点宕机了，那么运行期间就会重新进行leader的选举。

leader宕机之后，非observer节点都会把自己的状态修改为LOOKING状态，然后重新进入选举流程

生成投票信息(myid,zxid)，同样，第一轮的投票大家都会把票投给自己，然后把投票信息广播出去

接下来的流程和上面的选举是一样的，都会优先以zxid，然后选择myid，最后统计投票信息，修改节点状态，选举结束。

还是会存在的，可以分成3个场景来描述这个问题。

因为ZooKeeper是过半成功即代表成功，假设我们有5个节点，如果123节点写入成功，如果这时候请求访问到4或者5节点，那么有可能读取不到数据，因为可能数据还没有同步到4、5节点中，也可以认为这算是数据不一致的问题。

解决方案可以在读取前使用sync命令。

这也就是数据同步说过的问题。

leader刚生成一个proposal，还没有来得及发送出去，此时leader宕机，重新选举之后作为follower，但是新的leader没有这个proposal。

这种场景下的日志将会被丢弃。

如果发送proposal成功了，但是在将要发送commit命令前宕机了，如果重新进行选举，还是会选择zxid最大的节点作为leader，因此，这个日志并不会被丢弃，会在选举出leader之后重新同步到其他节点当中。

zookeeper Leader的选举过程

假如有三个节点(s1,s2,s3)组成的集群。在集群启动过程中并伍，当有一台zookeeper节点s1启动完成后，此时集群中只有一个节点铅迹无法进行leader的选举。当第二个节点s2启动成功后，此时两个节点可以正常通信，进入leader的选举过程，具体如下：

还是假如有三台服务器(s1,s2,s3)组成的集群,s2时leader。在集群运行槐蔽并中时，只有当集群中的leader宕机才会触发leader的重新选举，集群中follower宕机或者新节点的加入并不影响leader的地位。

选举过程如下：

Zookeeper之领导者选举算法源码分析

QuorumPeer继承了ZooKeeperThread线程类

org.apache.zookeeper.server.quorum.QuorumPeer#run

本地或远程注册

在循环内根据不同的状态运行

1、readonlymode

首先判断只读模式是否打开readonlymode.enabled默认是false

2、进行领导者选举

表示：zk1、zk2、zk3三台zk服务端（myid1=1、epoch1当前届改没数、zxid1是当前zk1服务的状态信息）。图中连线0表示把投给自己的选票并此肢放入sendqueue队列中，图中连线1表示发送给其他参与者(即是调用sendNotifications方法)，2表示从recvqueue接收队列获取的选票与当前服务器持有选票进行比较。

org.apache.zookeeper.server.quorum.FastLeaderElection#lookForLeader

1、第一次启动，默认投自己，并更新当前服务协议的领导者信息的值proposedLeader、proposedZxid、proposedEpoch

4、从recvqueue不断获取收到的投票信息

其他服森歼世务器的投票或投给自己的都放到这里

②、connectAll建立连接

org.apache.zookeeper.server.quorum.QuorumCnxManager#connectAll

org.apache.zookeeper.server.quorum.SyncedLearnerTracker#hasAllQuorums

是否过半判断

领导者角色已经确立，其他服务器启动角色处理

recvqueue数据是从Messenger.WorkerReceiver线程不断获取的

1、WorkerReceiver#run

org.apache.zookeeper.server.quorum.FastLeaderElection.Messenger.WorkerReceiver#run

2、不是有效的投票者

!validVoter(response.sid)表示是观察者

这里也进行了处理，把当前current的投票放入到sendqueue并返回给当前启动的那台服务器（通过response.sid）

把当前服务得到的currentVote放入到sendqueue队列，并返回发送给这台服务器

1、FOLLOWING节点挂了一半

org.apache.zookeeper.server.quorum.Leader#lead

不断向learners节点ping，如果挂了一半则会跳出循环leader.lead();阻塞被解除

org.apache.zookeeper.server.quorum.QuorumPeer#updateServerState

领导者选举算法核心就是把选票封装并放入到sendqueue集合发送，通过recvqueue得到其他服务节点的选票。并不断比较PK，更改选票并不断发送，并验证是否过半。如果过半则选举出来领导者。

领导者选举触发情况：刚启动、FOLLOWING节点挂了一半、LEADING节点挂掉

大数据Hadoop之ZooKeeper认识

Zookeeper字面上理解就是动物管理员，Hadoop生态圈中很多开源项目使用动物命名，那么需要一个管理员来管理这些“动物”。

在集群的管理中Zookeeper起到非常重要的角色，他负责分布式应用程序协调的工作。

Zookeeper管理集群会选举一个Leader节点（可参考FastLeader选举算法，即快速选举Leader节点），Leader节点主要负责整个Zookeeper集群的运行管理，Follower负责管理具体的数据存储与读取。

Zookeeper主要提供以下四点功能：统一命名服务、配置管理、集群管理、共享锁和队列管理，用于高效的管理集群的运行。

1. 统一命名服务

命名服务指通过指定的名字获取资源或者服务提供者的信息。分布式应用中，通常需要有一套完整的命名规则，既能够产生唯一的名称又便于识别和记忆。通常情况下使用空败树形的名称结构是一个理想的选择，树形的名称结构是一个有层次的目录结构，即对人友好又不会重复。

Zookeeper集群中统一由Leader节点（图中M节点）来管理所有Follower节点（图中的S1和S2节点）的命名空间。Zookeeper提供统一的命名服务，他不对外提供数据也不存储数据，他只提供一套统一的命名规则，运行在Zookeeper之上的服务需要遵循这一套命名规则。其中较为常见的就是一些分布式服务框架中的服务地址列表。通过调用ZK提供的创建节点的接口（API），能够很容易创建一个全局唯一的路径（path），这个path就可以作为一个名称。命名服务（NameService）已经是Zookeeper内置的功能，你只要调用Zookeeper的API就能实现。如调用create接口就可以很容易创建一个目录节点。

遵循Leader统一管理命名规则下，集群中数据读写的方式：

1.1.写数据，一个客户端进行写数据请求时，会指定Zookeeper集群节点，如果是Follower接收到写请求，会把请求转发给Leader，Leader通过内部的Zab协议进行原子广播，直到所有Zookeeper节点都成功写了数据，然后Zookeeper会给Client发回写完响应。

1.2.读数据，因为集群中Zookeeper按照统一的命名空间，所有Zookeeper节点呈现相同的命名空间视图（文件目录名称结构），所以读数据的时候请求任意一台Zookeeper节点都一样。

2. 配置管理

配置的管理在分布式应用环境中很常见，例如同一个应用需要在多台服务器上运行，但是它们的应用系统的某些配置相同的，如果要修改这些相同的配置项，就必须同时修改每台运行这个应用系统的PC Server，这样非常麻烦而且容易出错。像这样的配置信息完全可以交给Zookeeper来管理，处理起来非常便捷。

配置的管理包含发布和订阅两个过程，顾名思义就是将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中管理和动态更新。

如图所示，将配置信息保存在Zookeeper（Leader节点）的某一个目录中，然后将所有需要修改的应用机器订阅该Zookeeper（Leader节点）节点，一旦Leader节点发布新配置信息，每台订阅的机器就会收到Zookeeper的通知，然后从Zookeeper获取新的配置信息应用到系统中，完成配置的集中统一管理。

3. 集群管理

Zookeeper在集群管理中主要是集群监控和Leader选举。

3.1.集群管理

这通常用于那种对集群中机器状态、 ， 机器在线率有较高要求的场景，能够快速对集群中机器变化做出响应。这样的场景中，往往有一个监控系统，实时检测集群机器是否存活。过去的做法通常是：监控系统通过某种手段（比如ping）定时让扰检测每个机器，或者每个机器自己定时向监控系统汇报"我还活着"。

这种做法可行，但是存在两个比较明显的问题：

1）.集群中机器有变动的时候，牵连修改的东西比较多。

2）.有一定的延斗滑颤时。

利用ZooKeeper中两个特性，就可以实施另一种集群机器存活性监控系统：

1）.客户端在示例节点A上注册一个监控者（Watcher），那么如果A的子节点变化了，会通知该客户端。

2）.创建EPHEMERAL类型的节点，一旦客户端和服务器的会话结束或过期，那么该节点就会消失。

3.2.Leader选举：

Leader选举即从大量集群节点中选举一个Leader节点，是zookeeper中最为经典的使用场景，在分布式环境中选举的Leader节点好快会直接影响集群的效率。Leader节点主要负责相同的业务应用分布在不同的机器上共用的逻辑模型和数据的调配，优秀的调配方案可以大大减少重复运算，提高性能降低集群的负载。

利用ZooKeeper中两个特性，就可以实施另一种集群中Leader选举：

1）.利用ZooKeeper的强一致性，能够保证在分布式高并发情况下节点创建的全局唯一性，即：同时有多个客户端请求创建Leader节点，最终一定只有一个客户端请求能够创建成功。利用这个特性，就能很轻易的在分布式环境中进行集群的Leader选举了。

2）.另外，这种场景演化一下，就是动态Leader选举。这就要用到EPHEMERAL_SEQUENTIAL类型节点的特性了，这样每个节点会自动被编号。允许所有请求都能够创建成功，但是创建节点会为每个节点安排顺序，每次选取序列号最小的那个机器作为Leader。

小结

Zookeeper作为Hadoop主要的组件，在集群管理方面为我们提供了解决方案。通过对统一命名服务、配置管理和集群管理的阅读，我们能够清晰的理解Zookeeper的核心内容。针对共享锁和队列服务偏技术实现，有兴趣的可以进一步研究。

Zookeeper在大数据集群中解决集群管理的问题，磨刀不误砍柴工，了解完工具我们下一次分享一些具体的实效应用。

关于zookeeper选举和zookeeper选举协议的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。