Zookeeper详解（zk）

Zookeeper 概念

zooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google 的 Chubby 一个开源的实现，是 Hadoop 和 Hbase 的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括:配置维护、域名服务、分布式同步、组服务等。ZooKeeper 的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、 功能稳定的系统提供给用户。ZooKeeper 包含一个简单的原语集， 提供 Java 和 C 的接口 ，ZooKeeper 代码版本中，提供了分布式独享锁、选举、队列的接口，代码在 zookeeper-3.4.3\src\recipes。其中分布锁和队列有 Java 和 C 两个版本，选举只有 Java 版本
Zookeeper 是一个分布式协调服务，可用于服务发现，分布式锁，分布式领导选举，配置管理等。
Zookeeper 提供了一个类似于 Linux 文件系统的树形结构（可认为是轻量级的内存文件系统，但只适合存少量信息，完全不适合存储大量文件或者大文件），同时提供了对于每个节点的监控与通知机制
ZooKeeper 提供了什么：文件系统和通知机制

ZooKeeper的应用场景使用场景

Zookeeper的出现，主要是为了满足分布式环境中，以上三种常见的场景需求，作为一个分布式的中间件而存在。它相当于是一个分布式开源的协调组件。简单理解，就相当于是一个裁判员的角色，专门负责协调和解决分布式系统中的各类问题。
总的来说，Zookeeper 就是经典的分布式数据一致性解决方案，致力于为分布式应用提供高性能、高可用，并且具有严格顺序访问控制能力的分布式协调服务。它底层通过基于 Paxos 算法演化而来的 ZAB 协议实现。
1.服务注册与订阅（共用节点）
2.分布式通知（监听ZNode）
3.服务命令（ZNode特性）
4.数据订阅、发布（Watcher）
5.分布式锁（临时节点）

1. 集群管理
   Zookeeper 提供了 CP 的模型，来保证集群中的每个节点的数据一致性，当然Zk 本身的集群并不是 CP 模型，而是顺序一致性模型，如果要保证 CP 特性，需要调用 sync 同步方法。
   在多个节点组成的集群中，为了保证集群的 HA 特性，每个节点都会冗余一份数据副本。这种情况下需要保证客户端访问集群中的任意一个节点都是最新的数据。
2. 分布式锁
   Zookeeper 提供了多种不同的节点类型，如持久化节点、临时节点、有序节点、容器节点等，其中对于分布式锁这个场景来说，Zookeeper 可以利用有序节点的特性来实现。除此之外，还可以利用同一级节点的唯一性特性来实现分布式锁。
   对某一个数据联系发出两个修改操作，两台机器同时收到请求，但是只能一台 机器先执行另外一个机器再执行，那么此时就可以使用 zk 分布式锁，一个机器接收到了 请求之后先获取 zk 上的一把分布式锁，就是可以去创建一个 znode，接着执行操作，然 后另外一个机器也尝试去创建那个 znode，结果发现自己创建不了，因为被别人创建了， 那只能等着，等等一个机器执行完了自己再执行。
   如何保证跨进程的共享资源的并发安全性，对于分布式系统来说也是一个比较大的挑战，而为了达到这样一个目的，必须要使用跨进程的锁也就是分布式锁来实现。
3. Master 选举
   Zookeeper 可以利用持久化节点来存储和管理其他集群节点的信息，从而进行Master 选举机制。或者还可以利用集群中的有序节点特性，来实现 Master 选举。目前主流的 Kafka、Hbase、Hadoop 都是通过 Zookeeper 来实现集群节点的主从选举。
   在多个节点组成的集群中，为了降低集群数据同步的复杂度，一般会存在 Master和 Slave 两种角色的节点，Master 负责事务和非事务请求处理，Slave 负责非事务请求处理。但是在分布式系统中如何确定某个节点是 Master 还是 Slave，也成了一个难度不小的挑战。
   4.分布式协调：这个其实就是 zk 很经典的一个用法，简单来说，就好比，你系统 A 发送个 请求到 mq，然后 B 消费了之后处理。那 A 系统如何指导 B 系统的处理结果？用 zk 就可 以实现分布式系统之间的协调工作。A 系统发送请求之后可以在 zk 上对某个节点的值注 册个监听器，一旦 B 系统处理完了就修改 zk 那个节点的值，A 立马就可以收到通知，完美解决。
   5.配置信息管理：zk 可以用作很多系统的配置信息的管理，比如 kafka，storm 等等很多分 ，布式系统都会选用 zk 来做一些元数据，配置信息的管理，包括 dubbo 注册中心不也支持 zk 么。
   6.HA 高可用性：这个应该是很常见的，比如 hdfs，yarn 等很多大数据系统，都选择基于 zk 来发 HA 高可用机制，就是一个重要进程一般会主备两个，主进程挂了立马通过 zk 感知到切换到备份进程

zk的原理

ZooKeeper 是以 Fast Paxos 算法为基础的，Paxos 算法存在活锁的问题，即当有多个 proposer 交错提交时，有可能互相排斥导致没有一个 proposer 能提交成功，而 Fast Paxos 作了一些优化，通过选举产生一个 leader (领导者)，只有 leader 才能提交 proposer，具体 算法可见 Fast Paxos。因此，要想弄懂 ZooKeeper 首先得对 Fast Paxos 有所了解。
ZooKeeper 的基本运转流程:
1、选举 Leader。
2、同步数据。
3、选举 Leader 过程中算法有很多，但要达到的选举标准是一致的。
4、Leader 要具有最高的执行 ID，类似 root 权限。
5、集群中大多数的机器得到响应并 follow选出的 Leader。
数据结构Znode：zookeeper数据采⽤树形层次结构，和标准⽂件系统⾮常相似，树中每个节点被称为Znode；
通知机制Watcher：zookeeper可以为所有的读操作（exists()、getChilden()及getData()）设置watch，watch事件是⼀次性出发器，当watch的对象状态发⽣改变时，将会触发次对象上watch所对应的事件。watch事件将被异步的发送给客户端，并且zookeeper为watch机制提供了有序的⼀致性保证。
基本流程：分布式锁应用场景
1、传统的⼀主n从分布式系统，容易发⽣单点故障，传统解决方式是增加⼀个备⽤节点，定期给主节点发送Ping包，主节点回复ack，但是如果⽹络原因ack丢失，那么会出现两个主节点，造成数据混乱。
2、zookeeper的引⼊可以管理两个主节点，其中挂了一个，会将另外⼀个作为新的主节点，挂的节点回来时担任备⽤节点；

ZooKeeper、Nacos、Eureka 和 Consul区别

ZooKeeper、Nacos、Eureka 和 Consul 都是常见的服务发现和配置中心工具，它们在分布式系统中扮演着重要的角色，但在某些方面有一些区别。
ZooKeeper:
● 角色：ZooKeeper 最初设计作为一个分布式协调服务，用于提供分布式锁、命名服务、配置管理等功能。
● 一致性：ZooKeeper 采用 ZAB 协议（ZooKeeper Atomic Broadcast）保证数据一致性。
● 特点：ZooKeeper 是 Apache 软件基金会的顶级项目，稳定性高，被广泛应用于分布式系统。
● 使用场景：主要用于分布式协调和一致性需求，如分布式锁、队列等。
Nacos:
● 角色：Nacos 是阿里巴巴开源的注册中心和配置中心，支持服务发现、服务健康检查、动态配置等功能。
● 特点：Nacos 支持多种注册中心和配置中心模式，包括基于 DNS 和基于 RPC 的服务发现。
● 优势：Nacos 功能较为全面，支持更多新特性，如动态配置管理、服务路由等。
Eureka:
● 角色：Eureka 是 Netflix 开源的服务发现组件，主要用于服务注册与发现。
● 特点：Eureka 采用了 CAP 原则中的 AP 模型，即可用性优先，对一致性要求相对较低。
● 优势：Eureka 相对简单易用，适合快速搭建微服务架构。
Consul:
● 角色：Consul 是 HashiCorp 公司开源的服务网格解决方案，集成了服务发现、健康检查、KV 存储等功能。
● 特点：Consul 提供了一体化的服务注册和发现解决方案，支持多数据中心部署，具有较好的可扩展性和灵活性。
● 优势：Consul 对多数据中心支持较好，适合复杂环境下的服务治理需求。
总的来说，ZooKeeper 更注重分布式协调和一致性，Nacos 提供了更全面的服务注册与配置管理功能，Eureka 简单易用适合快速搭建微服务，Consul 则更适合复杂环境下的服务发现和治理需求。选择合适的工具取决于具体的业务场景和需求。

Zookeeper的数据结构

ZooKeeper 是一个开源的分布式应用程序协调服务，它提供了一个具有高度可靠性的分布式协调和同步的解决方案。ZooKeeper 使用了一些关键的数据结构来管理和维护其状态，这些数据结构主要包括：

1. ZNode（ZooKeeper节点）：
   ○ ZooKeeper 的基本数据单元。
   ○ 它类似于文件系统中的节点，但是它们是内存中的数据结构。
   ○ 每个 ZNode 都有一个路径名，路径名用斜杠（/）分隔，类似于文件系统中的绝对路径。
2. 节点树（Node Tree）：
   ○ ZooKeeper 维护一个由 ZNode 组成的层次化节点树。
   ○ 树的根节点被称为 “/”，并且所有的其他节点都是相对于根节点的路径来定义的。
3. Watchers（监视器）：
   ○ Watchers 是在节点发生变化时通知客户端的机制。
   ○ 客户端可以在 ZNode 上设置 Watcher，以便在该节点的数据发生更改、被删除或子节点更改时收到通知。
4. 数据模型：
   ○ 每个 ZNode 都可以包含数据和子节点。
   ○ 数据是存储在每个 ZNode 中的字节流。
   ○ 每个 ZNode 可以拥有多个子节点，每个子节点都有唯一的路径名。
5. ACL（访问控制列表）：
   ○ ZooKeeper 使用 ACL 控制对 ZNode 的访问权限。
   ○ 每个 ZNode 都有一个 ACL，它规定了谁可以对其执行读、写、创建和删除等操作。
6. 版本号：
   ○ 每个 ZNode 都有一个版本号。
   ○ 版本号用于标识 ZNode 的状态变化，包括数据和子节点的变化。
7. 临时节点和顺序节点：
   ○ ZooKeeper 支持临时节点和顺序节点。
   ○ 临时节点在客户端会话结束时被删除。
   ○ 顺序节点在创建时会被自动分配一个唯一的递增顺序号。

这些数据结构和机制共同构成了 ZooKeeper 的核心功能，使其能够有效地用于分布式系统中的协调和同步。

zk集群脑裂如何解决

解决ZooKeeper（ZK）集群脑裂问题的方法可以从多个方面入手。ZooKeeper是一个分布式协调服务，用于协调和管理分布式系统中的各种数据和状态信息，因此避免集群脑裂对于整个分布式系统的稳定性非常重要。
以下是一些解决ZooKeeper集群脑裂问题的建议：

1. 奇数节点：建议使用奇数个节点组成ZooKeeper集群，这样在遇到网络分区时能够更容易地保持大多数节点的一致性。
2. Quorum设置：通过设置适当的Quorum配置，确保在发生网络分区时仍然能够保持大多数节点的一致性，避免脑裂问题的发生。
3. 自动选主：配置ZooKeeper集群在发生领导者节点故障时能够自动选举新的领导者，避免因为领导者节点故障引起的脑裂问题。
4. 网络配置：合理配置网络参数，尽量减少网络延迟和丢包等问题，提高集群的通信可靠性。
5. 监控与报警：建立完善的监控系统，对ZooKeeper集群的状态进行实时监控，并设置相应的报警机制，及时发现并处理潜在的脑裂问题。
6. 节点健康检测：定期对ZooKeeper集群中的各个节点进行健康状态检测，及时发现故障节点并进行处理。
7. 自动恢复：实现自动故障转移和自动恢复机制，确保在发生节点故障或网络分区后，集群能够自动进行恢复和重新配置，避免脑裂问题的持续影响。
   通过以上措施，可以有效地减少ZooKeeper集群脑裂问题的发生，提高整个分布式系统的稳定性和可靠性。同时，还需要根据具体的环境和需求，结合实际情况进行更详细的系统设计和优化。

ZAB 协议

ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持崩溃恢复的原子广播协议。
ZAB 协议包括两种基本的模式：崩溃恢复和消息广播。
当整个 zookeeper 集群刚刚启动或者 Leader 服务器宕机、重启或者网络故障 导致不存在过 半的服务器与 Leader 服务器保持正常通信时，所有进程（服务 器）进入崩溃恢复模式，首 先选举产生新的 Leader 服务器，然后集群中 Follower 服务器开始与新的 Leader 服务器进 行数据同步，当集群中超过半数 机器与该 Leader 服务器完成数据同步之后，退出恢复模式 进入消息广播模 式，Leader 服务器开始接收客户端的事务请求生成事物提案来进行事务请求处理。

假如注册中心挂了，消费者还能调⽤服务吗，用什么调用的

1. 注册中心对等集群，任意一台宕掉后，会自动切换到另一台
2. 注册中心全部宕掉，服务提供者和消费者仍可以通过本地缓存通讯
3. 服务提供者无状态，任一台 宕机后，不影响使用
4. 服务提供者全部宕机，服务消费者会无法使用，并无限次重连等待服务者恢复

dubbo注册中心为什么选择 Zookeeper

可以选 Zookeeper，memcached，redis 等。
命名服务，服务提供者向 Zookeeper 指定节点写入 url，完成服务发布。
负载均衡，注册中心承载能力有限，而 Zookeeper 集群配合 web 应用很容易达到负载均衡。
zk 支持监听事件，特别适合发布/订阅场景，dubbo生产者和消费者就类似这场景。
数据模型简单，数据存在内存，可谓高性能
Dubbo 选择 Zookeeper 作为注册中心的原因有以下几点

1. 分布式特性
   Zookeeper 是一个分布式协调服务，具有良好的分布式特性和可靠性，适合作为 Dubbo 的注册中心。它可以实现分布式服务的注册与发现，保证服务的高可用性和一致性。
2. 节点管理
   Zookeeper 提供了节点管理和监控功能，可以轻松管理 Dubbo 微服务架构中的各个节点信息，包括服务提供者和消费者的注册信息、健康状态等。
3. 顺序一致性
   Zookeeper 提供了顺序一致性的特性，能够确保节点数据的一致性和可靠性。这对于服务注册中心来说非常重要，可以有效避免数据同步的问题。
4. Watcher 机制
   Zookeeper 支持 Watcher 机制，可以实现对节点变化的监听和通知，当服务提供者或消费者状态发生变化时，注册中心可以及时感知并通知相关节点。
5. 可靠性和稳定性
   Zookeeper 是一个经过大规模应用验证的成熟分布式系统，具有良好的可靠性和稳定性，能够保证 Dubbo 微服务架构的正常运行。
6. 社区支持
   Zookeeper 拥有活跃的社区和丰富的生态系统，可以获得及时的技术支持和更新迭代，能够满足 Dubbo 在注册中心方面的需求。
   综上所述，Zookeeper 作为 Dubbo 的注册中心具有良好的分布式特性、节点管理能力、一致性保证、Watcher 机制、稳定性和社区支持等优势，能够很好地满足 Dubbo 微服务架构的需求。因此，Dubbo 选择 Zookeeper 作为注册中心是基于以上考虑而做出的合理选择。

关于zookeeper部署的个数

你运行一个zookeeper也是可以的，但是在生产环境中，你最好部署3，5，7个节点。部署的越多，可靠性就越高，当然只能部署奇数个，偶数个是不可以的（zookeeper有这样一个特性：集群中只要有过半的机器是正常工作的，那么整个集群对外就是可用的。也就是说如果有2个zookeeper，那么只要有1个死了zookeeper就不能用了，因为1没有过半，所以2个zookeeper的死亡容忍度为0；同理，要是有3个zookeeper，一个死了，还剩下2个正常的，过半了，所以3个zookeeper的容忍度为1；同理你多列举几个：2->0;3->1;4->1;5->2;6->2会发现一个规律，2n和2n-1的容忍度是一样的，都是n-1，所以为了更加高效，何必增加那一个不必要的zookeeper呢）。你需要给每个zookeeper 1g左右的内存，如果可能的话，最好有独立的磁盘。 (独立磁盘可以确保zookeeper是高性能开发的。).如果你的集群负载很重，不要把zookeeper和regionserver运行在同一台机器上面。就像datanodes 和 tasktrackers一样

Zk分布式锁原理和实现

Zookeeper 是基于临时顺序节点以及 Watcher 监听器机制实现分布式锁的。
1.ZooKeeper 的每一个节点都是一个天然的顺序发号器。
2.ZooKeeper 节点的递增有序性可以确保锁的公平。
3.ZooKeeper 的节点监听机制，可以保障占有锁的传递有序而且高效
Zookeeper实现分布式锁原理：
Zookeeper节点路径不能重复 保证唯一性。 临时节点+事件通知
1.获取锁方法：
多个jvm同时在zk上创建一个临时节点/lockPath,
最终只能够有一个jvm创建临时节点成功，如果能够创建
临时节点成功jvm 表示获取锁成功能够正常执行业务逻辑，
如果没有创建临时节点成功的jvm，则表示获取锁失败。
获取锁失败之后，可以采用不断重试策略，重试多次
获取锁失败之后，当前的jvm就进入到阻塞状态。
2.释放锁方法：
直接调用.close();释放锁
因为采用临时节点，当我们调用close()方法的时候
该临时节点会自动被删除。
其他没有获取到锁的jvm，就会从新进入到获取锁的状态。
3.被唤醒的方法：
被阻塞的jvm（没有获取锁成功的jvm），采用事件监听的方式
监听到节点已经被删除的情况下，则开始从新进入到获取锁的状态。
Zookeeper 实现分布式锁的方法比较多，我们可以使用有序节点来实现，
1、来看这个图，每个线程或进程在 Zookeeper 上的/lock 目录下创建一个临时有序的节点表示去抢占锁，所有创建的节点会按照先后顺序生成一个带有序编号的节点。
2、线程创建节点后，获取/lock 节点下的所有子节点，判断当前线程创建的节点是否是所有的节点的序号最小的。
3、如果当前线程创建的节点是所有节点序号最小的节点，则认为获取锁成功。
4、如果当前线程创建的节点不是所有节点序号最小的节点，则对节点序号的前个节点添加一个事件监听，当前一个被监听的节点释放锁之后，触发回调通知，从而再次去尝试抢占锁。
ZooKeeper 是一种分布式协调服务，它可以帮助分布式系统中的各个节点进行协调和通信。ZooKeeper 的协调机制是通过一种称为 “ZNode” 的数据结构来实现的。
在 ZooKeeper 中，每个节点都被称为一个 ZNode，它可以有子节点和关联的数据。ZNode 可以被视为一种目录结构，其中每个节点都有一个路径。通过这个路径，可以找到节点的数据。
当使用 ZooKeeper 实现分布式锁时，可以使用一种称为 “顺序节点” 的机制。顺序节点是一种特殊的 ZNode，它会在创建时自动分配一个唯一的顺序编号。这个编号可以用来解决分布式锁的问题。
假设我们有一个需要被协调的任务，可以让多个进程都去创建 ZooKeeper 中的同一家目录下的一个子节点。由于是顺序节点，每个进程创建的子节点都会被分配一个唯一的编号。当一个进程创建了编号最小的子节点时，就认为它获得了锁，可以执行任务。其他进程在创建子节点时会被阻塞，等待前一个进程释放锁。
这个过程中，只要有一台机器能够成功创建子节点并获得锁，就可以完成任务。其他机器会继续等待，直到锁被释放。这样可以保证只有一个进程能够执行任务，实现分布式锁的效果。
总之，ZooKeeper 提供了分布式协调的机制，可以通过顺序节点实现分布式锁的功能，使得分布式系统中的任务可以被协调执行。

zk中的Watch机制的原理

Zookeeper是一个分布式协调组件，为分布式架构下的多个应用组件提供了顺序访问控制能力。
它的数据存储采用了类似于文件系统的树形结构，以节点的方式来管理存储在Zookeeper上的数据
Zookeeper提供了一个Watch机制，可以让客户端感知到Zookeeper Server上存储的数据变化，这样一种机制可以让Zookeeper实现很多的场景，比如配置中心、注册中心等。
Watch机制采用了Push的方式来实现，也就是说客户端和Zookeeper Server会建立一个长连接，一旦监听的指定节点发生了变化，就会通过这个长连接把变化的事件推送给客户端。
Watch的具体流程分为几个部分：
首先，是客户端通过指定命令比如exists、get，对特定路径增加watch
然后服务端收到请求以后，用HashMap保存这个客户端会话以及对应关注的节点路径，同时客户端
也会使用HashMap，存储指定节点和事件回调函数的对应关系。
当服务端指定被watch的节点发生变化后，就会找到这个节点对应的会话，把变化的事件和节点信息
发给这个客户端。客户端收到请求以后，从ZkWatcherManager里面对应的回调方法进行调用，完成事件变更的通知。
ZooKeeper 中的 Watch 机制是一种事件通知机制，在节点数据发生变化时，可以通知客户端进行相应的处理。以下是 ZooKeeper 中 Watch 机制的原理：

1. 注册 Watcher： 客户端可以在对节点进行操作（比如创建、更新、删除等）时，通过 API 注册 Watcher 监听这些节点的变化。客户端在注册 Watcher 时需要指定 Watcher 类型（比如节点数据变化、子节点列表变化等）和具体的节点路径。
2. Watch 持久化存储： 当节点数据发生变化时，ZooKeeper 会将变化事件保存到内存中，并向注册了对应 Watcher 的客户端发送通知，客户端接收到通知后会执行相应的回调函数。
3. 一次性触发： 一旦 Watcher 被触发，它就会被删除，因此每个 Watcher 只能触发一次。如果客户端需要持续监视节点的变化，需要在收到通知后重新注册 Watcher。
4. 版本号和序列号： ZooKeeper 使用版本号和序列号来标识节点的状态变化，客户端在注册 Watcher 时可以指定观察的节点状态版本号，当节点状态发生改变时，ZooKeeper 会比较版本号，并向注册的 Watcher 发送通知。
5. Watch 事件类型： ZooKeeper 提供了多种 Watch 事件类型，包括数据变更通知、子节点列表变更通知等。客户端可以根据需要注册不同类型的 Watcher。
   总的来说，ZooKeeper 中的 Watch 机制通过注册、通知和回调实现节点状态变化的监听和处理。客户端可以利用 Watch 机制实现对节点数据变化的实时感知，并及时作出相应的处理。这种机制在分布式系统中非常重要，能够帮助实现实时的状态同步和协调。

Zk实现Leader选举

Zookeeper集群节点由三种角色组成，分别是Leader，负责所有事务请求的处理，以及过半提交的投票发起和决策。Follower，负责接收客户端的非事务请求，而事务请求会转发给Leader节点来处理， 另外，
Follower节点还会参与Leader选举的投票。Observer，负责接收客户端的非事务请求，事务请求会转发给Leader节点来处理，另外Observer节点不参与任何投票，只是为了扩展Zookeeper集群来分担读操作的压力
其次，Zookeeper集群是一种典型的中心化架构，也就是会有一个Leader作为决策节点，专门负责事务请求的处理和数据的同步。这种架构的好处是可以减少集群架构里面数据同步的复杂度，集群管理会更加简单和稳定。但是，会带来Leader选举的一个问题，也就是说，如果Leader节点宕机了，为了保证集群继续提供可靠的服务，Zookeeper需要从剩下的Follower节点里面去选举一个新的节点作为Leader，也就是所谓的Leader选举
具体的实现是，每一个节点都会向集群里面的其他节点发送一个票据Vote，这个票据包括三个属性。
epoch， 逻辑时钟，用来表示当前票据是否过期。
zxid，事务id，表示当前节点最新存储的数据的事务编号。
myid，服务器id，在myid文件里面填写的数字。
每个节点都会选自己当Leader，所以第一次投票的时候携带的是当前节点的信息。
接下来每个节点用收到的票据和自己节点的票据做比较，根据epoch、zxid、myid的顺序逐一比较，以值最大的一方获胜。比较结束以后这个节点下次再投票的时候，发送的投票请求就是获胜的Vote信息。然后通过多轮投票以后，每个节点都会去统计当前达成一致的票据，以少数服从多数的方式，最终获得票据最多的节点成为Leader。
以上就是我对这个问题的理解。
最后我再补充一下，选择epoch/zxid/myid作为投票评判依据的原因，我是这么理解的。
epoch ，因为网络通信延迟的可能性，有可能在新一轮的投票里面收到上一轮投票的票据，这种数据应该丢弃，否则会影响投票的结果和效率。
zxid，zxid越大，说明这个节点的数据越接近leader，所以用zxid做判断条件是为了避免数据丢失的问题。myid， 服务器id，这个是避免投票时间过长，直接用myid最大值作为快速终结投票的属性。