Zookeeper 概念与原理介绍

中间件：Zookeeper
注：本文是作者学习Zookeeper时得笔记和经验总结

1. ZooKeeper 特点

• 顺序一致性：从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到 ZooKeeper 中去。
• 原子性：所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用。
• 单一系统映像：无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的。
• 可靠性：一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖。

2. 重要概念总结：

• ZooKeeper 本身就是一个分布式程序（只要半数以上节点存活，ZooKeeper 就能正常服务）。
• 为了保证高可用，最好是以集群形态来部署 ZooKeeper，这样只要集群中大部分机器是可用的（能够容忍一定的机器故障，最大容忍故障为： 小于总数/2. 例如：7台机器，最大容忍宕机为3台），那么 ZooKeeper 本身仍然是可用的。
• ZooKeeper 将数据保存在内存中，这也就保证了 高吞吐量和低延迟（但是内存限制了能够存储的容量不太大，此限制也是保持 Znode 中存储的数据量较小的进一步原因）。
• ZooKeeper 是高性能的。在“读”多于“写”的应用程序中尤其地高性能，因为“写”会导致所有的服务器间同步状态。（“读”多于“写”是服务协调的主要应用场景。）
• ZooKeeper 有临时节点的概念。当创建临时节点的客户端会话一直保持活动，临时节点就一直存在。而当会话终结时，临时节点被删除。持久节点是指一旦这个 ZNode 被创建了，除非主动进行 ZNode 的移除操作，否则这个 ZNode 将一直保存在 Zookeeper 上。
• ZooKeeper 底层其实只提供了两个功能：① 管理（存储、读取）用户程序提交的数据；②为用户程序提交数据节点监听服务。

3. Zookeeper的角色

• 领导者（leader），负责进行投票的发起和决议，更新系统状态
• 学习者（learner），包括跟随者（follower）和观察者（observer）
• follower用于接受客户端请求并向客户端返回结果，在选主过程中参与投票 ; Observer可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度.

4. 状态

• LOOKING：当前集群中没有选取出来leader时，所有节点得状态都为LOOKING
• LEADING： leader节点对应得状态
• FOLLOWING ：所有得follower节点对应得状态
  Zookeeper集群选主后
  Zookeeper集群选主前
• Follower主要有四个功能：

  1. 向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）
  2. 接收Leader消息并进行处理
  3. 接收Client的请求，如果为写请求，发送给Leader进行投票
  4. 返回Client结果

• Follower会循环处理如下几种来自Leader的消息：

  1. PING消息： 心跳消息
  2. PROPOSAL消息：Leader发起的提议，要求Follower投票
  3. COMMIT消息：服务器端最新一次提案的信息
  4. UPTODATE消息：表明同步完成
  5. REVALIDATE消息：根据Leader的REVALIDATE结果，关闭待revalidate的session还是允许其接受消息
  6. SYNC消息：返回SYNC结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新

5. Znode

• 在谈到分布式的时候，我们通常说的“节点"是指组成集群的每一台机器。然而，在 ZooKeeper 中，“节点"分为两类：

  1. 第一类同样是指构成集群的机器，我们称之为机器节点。
  2. 第二类则是指数据模型中的数据单元，我们称之为数据节点一ZNode。

• ZooKeeper 将所有数据存储在内存中，数据模型是一棵树（Znode Tree)，由斜杠（/）的进行分割的路径，就是一个 Znode，例如/foo/path1。每个上都会保存自己的数据内容，同时还会保存一系列属性信息。
• ZooKeeper ：部署在远程主机上的 ZooKeeper 集群，当然，也可能是单机的。
• Client ：分布在各处的 ZooKeeper 的 jar 包程序，被引用在各个独立应用程序中。
• WatchManager ：一个接口，用于管理各个监听器，只有一个方法 materialize()，返回一个 Watcher 的 set。

6. Watcher 机制

• Watcher（事件监听器），是 ZooKeeper 中的一个很重要的特性。客户端在向 ZooKeeper 服务器注册 Watcher 的同时，会将 Watcher 对象存储在客户端的 WatchManager 中。当ZooKeeper 服务器触发 Watcher 事件后(比如 新增、删除等操作)，会向客户端发送通知，客户端线程从 WatchManager 的实现类中取出对应的 Watcher 对象来执行回调逻辑。

7. 👍👍工作原理👍👍

• Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式和广播模式。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。
• 一旦leader已经和多数的follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个server加入zookeeper服务中，它会在恢复模式下启动，发现leader，并和leader进行状态同步。待到同步结束，它也参与消息广播。Zookeeper服务一直维持在Broadcast状态，直到leader崩溃了或者leader失去了大部分的followers支持。
• 广播模式需要保证proposal被按顺序处理，因此zk采用了递增的事务id号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了zxid。实现中zxid是一个64为的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch。低32位是个递增计数。
• 当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的server都恢复到一个正确的状态。
• 每个Server启动以后都询问其它的Server它要投票给谁。
• 对于其他server的询问，server每次根据自己的状态都回复自己推荐的leader的id和上一次处理事务的zxid（系统启动时每个server都会推荐自己）。
• 👍收到所有Server回复以后，就计算出zxid最大的哪个Server，并将这个Server相关信息设置成下一次要投票的Server。
• 👍计算这过程中获得票数最多的的sever为获胜者，如果获胜者的票数超过半数，则改server被选为leader。否则，继续这个过程，直到leader被选举出来。
• leader就会开始等待server连接。
• 👍Follower连接leader，将最大的zxid发送给leader，Leader根据follower的zxid确定同步点，完成同步后通知follower 已经成为uptodate状态，Follower收到uptodate消息后，又可以重新接受client的请求进行服务了。

8. 👍👍ZAB介绍

• ZAB协议全称就是ZooKeeper Atomic Broadcast protocol，是ZooKeeper用来实现一致性的算法( 实现了 paxos一致性算法)，涉及几个名词：

  1. electionEpoch：每执行一次leader选举，electionEpoch就会自增，用来标记leader选举的轮次
  2. peerEpoch：每次leader选举完成之后，都会选举出一个新的peerEpoch，用来标记事务请求所属的轮次
  3. zxid：事务请求的唯一标记，由leader服务器负责进行分配。由2部分构成，高32位是上述的peerEpoch，低32位是请求的计数，从0开始。所以由zxid我们就可以知道该请求是哪个轮次的，并且是该轮次的第几个请求。
  4. lastProcessedZxid：最后一次commit的事务请求的zxid

• 分成如下4个阶段：

  1. Leader election：leader选举过程，electionEpoch自增，在选举的时候lastProcessedZxid越大，越有可能成为leader。
  2. Discovery：第一：leader收集follower的lastProcessedZxid，这个主要用来通过和leader的lastProcessedZxid对比来确认follower需要同步的数据范围；第二：选举出一个新的peerEpoch，主要用于防止旧的leader来进行提交操作（旧leader向follower发送命令的时候，follower发现zxid所在的peerEpoch比现在的小，则直接拒绝，防止出现不一致性）
  3. Synchronization：follower中的事务日志和leader保持一致的过程，就是依据follower和leader之间的lastProcessedZxid进行。follower多的话则删除掉多余部分，follower少的话则补充，一旦对应不上则follower删除掉对不上的zxid及其之后的部分然后再从leader同步该部分之后的数据。
  4. Broadcast：正常处理客户端请求的过程。leader针对客户端的事务请求，然后提出一个议案，发给所有的follower，一旦过半的follower回复OK的话，leader就可以将该议案进行提交了，向所有follower发送提交该议案的请求，leader同时返回OK响应给客户端。

9. 特殊情况的注意点

• 事务日志和事务快照日志的持久化和恢复 ：
  • Broadcast过程的持久化：

  1. leader针对每次事务请求都会生成一个议案，然后向所有的follower发送该议案.
  2. follower接收到该议案后，所做的操作就是将该议案记录到事务日志中，每当记满100000个（默认），则事务日志执行flush操作，同时开启一个新的文件来记录事务日志
  3. 同时会执行内存树的快照，snapshot.[lastProcessedZxid]作为文件名创建一个新文件，快照内容保存到该文件中。

  • leader shutdown过程的持久化 : 一旦leader过半的心跳检测失败，则执行shutdown方法，在该shutdown中会对事务日志进行flush操作
  • 事务快照的恢复 :

  1. 会在事务快照文件目录下找到最近的100个快照文件，并排序，最新的在前
  2. 对上述快照文件依次进行恢复和验证，一旦验证成功则退出，否则利用下一个快照文件进行恢复。恢复完成更新最新的lastProcessedZxid。

  • 事务日志的恢复 :

  1. 从事务日志文件目录下找到zxid大于等于上述lastProcessedZxid的事务日志
  2. 然后对上述事务日志进行遍历，应用到ZooKeeper的内存树中，同时更新lastProcessedZxid
  3. 同时将上述事务日志存储到committedLog中，并更新maxCommittedLog、minCommittedLog.

• 由此我们可以看到，在初始化恢复的时候，是会将所有最新的事务日志作为已经commit的事务来处理的.也就是说这里面可能会有部分事务日志还没真实提交，而这里全部当做已提交来处理。这个处理简单粗暴了一些，而raft对老数据的恢复则控制的更加严谨一些。

1. ☛ 文章要是勘误或者知识点说的不正确，欢迎评论，毕竟这也是作者通过阅读源码获得的知识，难免会有疏忽！
2. ☛ 要是感觉文章对你有所帮助，不妨点个关注，或者移驾看一下作者的其他文集，也都是干活多多哦，文章也在全力更新中。
3. ☛ 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处！