Zookeeper概述

什么是zookeeper

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。

简单来说zookeeper=文件系统+监听通知机制

zookeeper的作用

• 命名服务
• 配置管理
• 集群管理
• 分布式锁
• 队列管理

znode节点类型

• 持久化目录节点（PERSISTENT ）
  客户端与zookeeper断开连接后，该节点依旧存在

• 持久化顺序编号目录节点（PERSISTENT_SEQUENTIAL）
  客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号

• 临时目录节点（EPHEMERAL）
  客户端与zookeeper断开连接后，该节点被删除

• 临时顺序编号目录节点（EPHEMERAL_SEQUENTIAL）
  客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

高可用

leader选举

zookeeper leader 选举

服务器启动时期的Leader选举

若进行Leader选举，则至少需要两台机器，这里选取3台机器组成的服务器集群为例。在集群初始化阶段，当有一台服务器Server1启动时，其单独无法进行和完成Leader选举，当第二台服务器Server2启动时，此时两台机器可以相互通信，每台机器都试图找到Leader，于是进入Leader选举过程。选举过程如下

• 每个Server发出一个投票。由于是初始情况，Server1和Server2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid和ZXID，使用(myid, ZXID)来表示，此时Server1的投票为(1, 0)，Server2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器；

• 接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器；

• 处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK，PK规则如下：

  1. 优先检查ZXID。ZXID比较大的服务器优先作为Leader。
  2. 如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器。
  3. 对于Server1而言，它的投票是(1, 0)，接收Server2的投票为(2, 0)，首先会比较两者的ZXID，均为0，再比较myid，此时Server2的myid最大，于是更新自己的投票为(2, 0)，然后重新投票，对于Server2而言，其无须更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可。

• 统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于Server1、Server2而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出了Leader；

• 改变服务器状态。一旦确定了Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变更为FOLLOWING，如果是Leader，就变更为LEADING；

服务器运行时期的Leader选举

在Zookeeper运行期间，Leader与非Leader服务器各司其职，即便当有非Leader服务器宕机或新加入，此时也不会影响Leader，但是一旦Leader服务器挂了，那么整个集群将暂停对外服务，进入新一轮Leader选举，其过程和启动时期的Leader选举过程基本一致。假设正在运行的有Server1、Server2、Server3三台服务器，当前Leader是Server2，若某一时刻Leader挂了，此时便开始Leader选举。

选举过程如下：

• 变更状态。Leader挂后，余下的非Observer服务器都会讲自己的服务器状态变更为LOOKING，然后开始进入Leader选举过程。
• 每个Server会发出一个投票。在运行期间，每个服务器上的ZXID可能不同，此时假定Server1的ZXID为123，Server3的ZXID为122；在第一轮投票中，Server1和Server3都会投自己，产生投票(1, 123)，(3, 122)，然后各自将投票发送给集群中所有机器。
• 接收来自各个服务器的投票。与启动时过程相同。
• 处理投票。与启动时过程相同，此时，Server1将会成为Leader。
• 统计投票。与启动时过程相同。
• 改变服务器的状态。与启动时过程相同。

数据同步

使用2PC两段式提交确保数据一致性

为什么建议集群节点建议为奇数个节点

zookeeper集群节点数需要超过半数，整个集群对外才可用。这里所谓的整个集群对外才可用，是指整个集群还能选出一个Leader来，zookeeper默认采用quorums来支持Leader的选举。

quorums机制有两个作用：

• 可以保证集群中选举出leader，且是唯一的一个，不会出现脑裂(split-brain)；
• 当客户端更新数据时，当大多数节点更新成功，客户端就会被通知更新成功了，其他节点可以稍后再更新，以致达到数据的最终一致性；

举个列子（设集群的最少节点数为n）：

集群总节点数	最少可用的节点数	可容忍失效的节点数
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2
6	4	2
...	...	...
2n-1	n	n-1
2n	n+1	n-1

由此可见：当集群总数为1或2，都不行，因为可容忍失效的节点数都为0，所以要想保证zookeeper的高可用，至少需要3台+。同时，我们可以发现一个规律，3个节点与4个节点的效果是一样的，可容忍失效的节点数都是1，即2n-1与2n，可容忍失效的节点数都是n-1。2n-1个节点能达到的效果，为啥要用2n个节点呢？
省一台主机，节省了成本。配置成偶数台也不会有问题，只不过浪费了而已。

脑裂现象

ZooKeeper集群中的节点应为网络或者其他原因，监听不到leader节点的心跳，就会认为leader节点出了问题，此时集群将分裂为不同的小集群，这些小集群会各自选举出自己的leader节点，导致原有的集群中出现多个leader节点。

解决方法
ZooKeeper默认采用了Quorums(法定人数)的方式：只有获得超过半数节点的投票，才能选举出leader。这种方式可以确保要么选出唯一的leader，要么选举失败。