ZooKeeper工作机制与应用场景

1.1、概述

        本文主要讲述ZooKeeper工作机制与应用场景，关于ZooKeeper的核心概念、主要特征等内容请参考构建分布式系统的一致性基石之ZooKeeper简介这篇博文。

1.2、选举机制

        ZooKeeper的选举机制基于ZAB协议（ZooKeeper Atomic Broadcast），这是一种为分布式系统设计的原子广播协议。其核心目标是快速选举出Leader节点，并确保数据一致性。

1.2.1、选举触发条件

• 集群初始化时
          所有节点启动时均为LOOKING状态，触发首次选举。
• 运行期间Leader故障时
          Leader节点宕机或网络中断时，剩余节点重新选举。

1.2.2、选举规则

• ZXID（事务ID）优先
          ZXID是64位整数，由epoch（任期）和counter（事务计数器）组成，数值越大表示数据越新，优先级更高。
• SID（服务器ID）次之
          若ZXID相同，则SID（配置文件中的myid）较大的节点胜出。
• 过半原则
          候选节点需获得超过半数投票（即N/2 +1）才能成为Leader。

1.2.3、选举过程详解

        假设有五台服务器组成的Zookeeper集群，它们的id从1-5，在集群初次启动时是没有历史数据，数据操作的事务ID也不存在，其选举流程如下：

• 服务器1
          服务器1启动，发起投票，投票格式为(Zxid，ServerID),投出的票为(0,1)，此时服务器1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为LOOKING。
• 服务器2
          服务器2启动，发起投票，投出的票为(0，2)，服务器1和2分别投自己一票并交换选票信息：此时服务器1发现服务器2的ServerID比自己目前投票推举的（服务器1）大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持LOOKING。
• 服务器3
          服务器3启动，发起投票，投出的票为(0，3)，此时服务器1和服务器2发现服务器3的ServerID比自己目前投票推举的（服务器2）大，更改选票为推举服务器3。此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING。
• 服务器4
          服务器4启动，发起投票。此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING。
• 服务器5
          服务器5启动，同服务器4启动过程类似。

Zookeeper集群的中每个服务器的数据都是一致的，除非网络波动极大，才会导致Zxid不一致，故而每个服务器的Zxid一致。如果真的遇到Zxid不一致，那么最大的Zxid的服务器会自动当选leader，如果相当则按照上述规则进行选举。

        运行期间的Leader故障时，所有FOLLOWING节点切换为LOOKING状态。此时触发重新选举Leader的过程，假设服务器3宕机时，服务器1的Zxid为100，服务器2的Zxid为101，服务器4的Zxid为104，服务器5的Zxid为105其选举流程如下：

• 所有服务器给自己投票
          此时服务器1、服务器2、服务器4、服务器5都为1票，服务器1、服务器2、服务器4、服务器5的状态都为LOOKING。
• 投票比较
          服务器1发现服务器5的Zxid最大，更改选票为推举服务器5。服务器2发现服务器5的Zxid最大，更改选票为推举服务器5。服务器4发现服务器5的Zxid最大，更改选票为推举服务器5。
• 投票确认
          服务器1为0票，服务器2为0票，服务器4为0票，服务器5为4票。此时服务器4的票数已经超过半数，服务器4当选Leader。服务器1，2、4更改状态为FOLLOWING，服务器5更改状态为LEADING。

1.3、数据同步机制

        zookeeper 的数据同步是为了保证各节点中数据的一至性，同步时涉及两个流程:

• 一个是正常的客户端数据提交
• 一个是集群某个节点宕机在恢复后的数据同步

1.3.1、正常同步

        当leader 接收客户端写请求，并同步给各个子节点的流程如下：

        但实际情况要复杂的多，比如client 它并不知道哪个节点是leader 有可能写的请求会发给follower ，由follower在转发给leader进行同步处理，如下：

        client向zk中的server发送写请求到达follower，follower则会将该写请求转发给leader，leader将请求事务以proposal形式分发给follower；
        当follower收到收到leader的proposal时，根据接收的先后顺序处理proposal；
        当Leader收到follower针对某个proposal过半的ack后，则发起事务提交，重新发起一个commit的proposal
        follower收到commit的proposal后，记录事务提交，并把数据更新到内存数据库；
当写成功后，反馈给client。

1.3.2、宕机同步

        在集群运行过程当中如果有一个follower节点宕机，由于宕机节点没过半，集群仍然能正常服务。当leader 收到新的客户端请求，此时无法同步给宕机的节点。造成数据不一至。为了解决这个问题，当节点启动时，第一件事情就是找当前的Leader，比对数据是否一至。不一至则开始同步,同步完成之后在进行对外提供服务。 如何比对Leader的数据版本呢，这里通过ZXID事务ID来确认。

ZXID是一个长度64位的数字，其中低32位是按照数字递增，任何数据的变更都会导致,低32位的数字简单加1。高32位是leader周期编号，每当选举出一个新的leader时，新的leader就从本地事物日志中取出ZXID,然后解析出高32位的周期编号，进行加1，再将低32位的全部设置为0。这样就保证了每次新选举的leader后，保证了ZXID的唯一性而且是保证递增的。

1.4、客户端常用命令

• 启动客户端
  zkCli.sh
• 查看帮助
  help
• 查看当前znode所包含的内容
  ls /
• 创建节点
  create /hello 18
• 创建短暂znode
  create -e /haha tom
• 创建带序号znode
  create -s /bigdata tom
• 创建短暂带序号
  create -e -s /bigdata tom
• 查看此节点的详细信息
  ls2 /
• 获得节点值监听
  get /hello watch
• 监听路径
  ls / watch
• 修改znode数据
  set /hello iiiii
• 删除节点
  delete /hello
• 递归删除
  rmr /delireba
• 查看节点状态信息
  stat /

1.5、应用场景

        ZooKeeper 是一个高可用的分布式数据管理与协调框架。基于对 ZAB 算法的实现， 该框架能够很好地保证分布式环境中数据的一致性。也是基于这样的特性，使得ZooKeeper 成为了解决分布式一致性问题的利器，其具有以下几种典型的应用场景。

1.5.1、配置管理

        zookeeper 提供了节点watch的功能，zookeeper 的 client（对外提供服务的 server）监控 zookeeper 上的节点（znode），当节点变动的时候，client 会收到变动事件和变动后的内容，基于 zookeeper 的这个特性，我们可以给服务器集群中的所有机器 （client）都注册 watch 事件，监控特定 znode，节点中存储部署代码的配置信息， 需要更新代码的时候，修改 znode 中的值，服务器集群中的每一台 server 都会收到代码更新事件，然后触发调用，更新目标代码。
        现在有很多开源项目使用 Zookeeper 来维护配置，比如在 HBase 中，客户端就是连接一个 Zookeeper，获得必要的 HBase 集群的配置信息，然后才可以进一步操作。 还有在开源的消息队列 Kafka 中，也使用 Zookeeper 来维护 broker 的信息。其原理如下：

1.5.2、命令服务

        命名服务也是分布式系统中比较常见的一类场景。在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。

        注册一个持久节点/service/business/what，他下面的每个子节点都是一个可用服务 ， 保 存 了 服 务 的 地 址 端 口 等 信 息 ， 服 务 调 用 者 通 过 zookeeper 获 取 /service/business/what 所有子节点信息来得到可用的服务。
        下面的节点都是临时节点，服务器启动的时候会过来注册一个临时节点，服务器挂掉之后或主动关闭之后，临时节点会自动移除，这样就可以保证使用者获取的 what 服务都是可用的，而且可以动态的扩容缩容。

1.5.3、分布式锁服务

        一个集群是一个分布式系统，由多台服务器组成。为了提高并发度和可靠性，多台服务器上运行着同一种服务。当多个服务在运行时就需要协调各服务的进度，有时候需要保证当某个服务在进行某个操作时，其他的服务都不能进行该操作，即对该操作进行加锁，如果当前机器挂掉后，释放锁并fail over 到其他的机器继续执行该服务。

1.5.4、集群管理

        一个集群有时会因为各种软硬件故障或者网络故障，出现某些服务器挂掉而被移除集群，而某些服务器加入到集群中的情况，zookeeper会将这些服务器加入/移出的情况通知给集群中的其他正常工作的服务器，以及时调整存储和计算等任务的分配和执行等。此外zookeeper还会对故障的服务器做出诊断并尝试修复。

1.5.5、分布式ID

        在过去的单库单表型系统中，通常可以使用数据库字段自带的auto_increment属性来自动为每条记录生成一个唯一的ID。但是分库分表后，就无法在依靠数据库的auto_increment属性来唯一标识一条记录了。此时我们就可以用zookeeper在分布式环境下生成全局唯一ID。做法如下：每次要生成一个新id时，创建一个持久顺序节点，创建操作返回的节点序号，即为新id，然后把比自己节点小的删除即可。

1.5.6、分布式协调/通知

        ZooKeeper 中特有 Watcher 注册与异步通知机制，能够很好的实现分布式环境下不同机器，甚至不同系统之间的通知与协调，从而实现对数据变更的实时处理。使用方法通常是不同的客户端都对 ZooKeeper 上同一个 ZNode 进行注册，监听ZNode 的变化（包括 ZNode 本身内容及子节点的），如果 ZNode 发生了变化，那么所有订阅的客户端都能够接收到相应的 Watcher 通知，并做出相应的处理。 ZooKeeper 的分布式协调/通知，是一种通用的分布式系统机器间的通信方式。

1.5.7、心跳检测

        机器间的心跳检测机制是指在分布式环境中，不同机器（或进程）之间需要检测到彼此是否在正常运行，例如 A 机器需要知道 B 机器是否正常运行。在传统的开 发中，我们通常是通过主机直接是否可以相互 PING 通来判断，更复杂一点的话， 则会通过在机器之间建立长连接，通过 TCP 连接固有的心跳检测机制来实现上层 机器的心跳检测，这些都是非常常见的心跳检测方法。 基于 ZooKeeper 的临时节点的特性，可以让不同的进程都在 ZooKeeper 的一个指定节点下创建临时子节点，不同的进程直接可以根据这个临时子节点来判断对应 的进程是否存活。通过这种方式，检测和被检测系统直接并不需要直接相关联，而是通过 ZooKeeper 上的某个节点进行关联，大大减少了系统耦合。