Zookeeper总结

1 ZK是什么

• ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
• 是使用了一种称为ZooKeeperAtomic Broadcast(ZAB,zookeeper原子消息广播协议)的协议作为其数据一致性的核心算法
• 目前很多大型的开源项目都在使用zookeeper，包括Hadoop、HBase、kafka等

设计目的

• 最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。 
• 可靠性：具有简单、健壮、良好的性能，如果消息被到一台服务器接受，那么它将被所有的服务器接受。 
• 实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。 
• 等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。 
• 原子性：更新只能成功或者失败，没有中间状态。 

1.1 ZAB协议概述

• ZooKeeper Atomic Broadcast(ZAB,zookeeper原子消息广播协议)协议作为其数据一致性的核心算法。
• ZAB协议是为分布式协调服务ZooKeeper专门设计的一种支持漰溃恢复的原子广播协议。
• ZooKeeper实现了一种主备模式的系统架构来保持集群中各副本之间数据的一致性。具体，ZooKeeper使用一个单一的主进程来接收并处理客户端的所有事务请求，并采用ZAB的原子广播协议，将服务器的状态变更以事务Proposal的形式广播到所有的副本进程上去。ZAB协议的这个主备模型架构保证了同一时刻集群中只能够有一个主进程来广播服务器的状态变更，因此能够很好地处理客户端大量并发请求。
• 所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器称为Leader服务器，而余下的其他服务器则成为Follower服务器。Leader服务器负责将一个客户端事务请求转换成一个事务Proposal(提议)，并将该Proposal分发给集群中所有的Follower服务器。之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求其将前一个Proposal进行提交。

 

1.2 Zk提供了什么

文件系统：每个子目录项都被称作为znode，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。

通知机制：客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端

znode类型

•  PERSISTENT-持久化目录节点 ：客户端与zookeeper断开连接后，该节点依旧存在 
• PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点 ：客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号 
• EPHEMERAL-临时目录节点 ：客户端与zookeeper会话失效后，该节点被删除 
• EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点 客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号 
•  

1.3 ZK做了什么

• 命名服务
• 配置管理
• 集群管理:所谓集群管理无在乎两点：是否有机器退出和加入、选举master。 对于第一点，所有机器约定在父目录GroupMembers下创建临时目录节点，然后监听父目录节点的子节点变化消息。一旦有机器挂掉，该机器与 zookeeper的连接断开，其所创建的临时目录节点被删除，所有其他机器都收到通知：某个兄弟目录被删除，于是，所有人都知道：它退出了。新机器加入也是类似，所有机器收到通知：新兄弟目录加入
• 分布式锁:有了zookeeper的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是保持独占，另一个是控制时序。 
  对于第一类，我们将zookeeper上一个znode看作是一把锁，通过createznode方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端拥有了这把锁。用完删除掉自己创建的distribute_lock 节点就释放出锁。 
  对于第二类， /distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，编号最小的获得锁，用完删除，依次方便。

• 队列管理:两种类型的队列
  1、同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。 
  2、队列按照 FIFO 方式进行入队和出队操作。 
  第一类，在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目。 
  第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。

2.1 ZK-角色描述

Zookeeper作为一个集群提供一致的数据服务，自然，它要在所有机器间做数据复制。数据复制的好处： 

•  容错：一个节点出错，不致于让整个系统停止工作，别的节点可以接管它的工作； 
•  提高系统的扩展能力 ：把负载分布到多个节点上，或者增加节点来提高系统的负载能力； 
•  提高性能：让客户端本地访问就近的节点，提高用户访问速度。 

 通过增加机器，zk的读吞吐能力和响应能力扩展性非常好，而写，随着机器的增多吞吐能力肯定下降，响应能力则取决于具体实现方式，是延迟复制保持最终一致性，还是立即复制快速响应。

2.2 ZK-特性

• 读、写模式:在ZooKeeper集群中，读可以从任意一个ZooKeeperServer读，这一点是保证ZK比较好的读性能的关键；写的请求会先Forword到Leader，然后由Leader来通过ZooKeeper中的原子广播协议，将请求广播给所有的Follower，Leader收到一半以上的写成功的Ack后，就认为该写成功了，就会发起commit操作，将写进行持久化，并告诉客户端写成功了。

• WAL和Snapshot
  和大多数分布式系统一样，ZooKeeper也有WAL(Write-Ahead-Log)，对于每一个更新操作，ZooKeeper都会先写WAL, 然后再对内存中的数据做更新，然后向Client通知更新结果。另外，ZooKeeper还会定期将内存中的目录树进行Snapshot，落地到磁盘上，这个跟HDFS中的FSImage是比较类似的。这么做的主要目的，一当然是数据的持久化，二是加快重启之后的恢复速度，如果全部通过Replay WAL的形式恢复的话，会比较慢。
• FIFO
  对于每一个ZooKeeper客户端而言，所有的操作都是遵循FIFO顺序的，这一特性是由下面两个基本特性来保证的：一是ZooKeeperClient与Server之间的网络通信是基于TCP，TCP保证了Client/Server之间传输包的顺序；二是ZooKeeperServer执行客户端请求也是严格按照FIFO顺序的。
• Linearizability
  在ZooKeeper中，所有的更新操作都有严格的偏序关系，更新操作都是串行执行的，这一点是保证ZooKeeper功能正确性的关键。

2.3 ZK-选 举 策 略 

ZK核心机制包括：恢复模式（选主流程）和广播模式（同步流程）。

当服务刚启动、leader 崩溃、follower 不足半数时，系统就进入选主流程，此时不对外提供服务；

当 leader被选举出来后，系统就进入同步流程，server 之间完成状态同步，此后对外提供服务。

选主主 要 基 于 paxos 算 法 ， 一 种 称 为 LeaderElection 算 法 ， 一 种 称 为Fast LeaderElection 算法，系统默认使用 Fast LeaderElection 算法完成。

LeaderElection 算 法:

1. 选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的Server； 
2. 选举线程首先向所有Server发起一次询问(包括自己)； 
3. 选举线程收到回复后，验证是否是自己发起的询问(验证zxid是否一致)，然后获取对方的id(myid)，并存储到当前询问对象列表中，最后获取对方提议的leader相关信息(id,zxid)，并将这些信息存储到当次选举的投票记录表中； 
4. 收到所有Server回复以后，就计算出zxid最大的那个Server，并将这个Server相关信息设置成下一次要投票的Server； 
5. 线程将当前zxid最大的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得n/2 + 1的Server票数，设置当前推荐的leader为获胜的Server，将根据获胜的Server相关信息设置自己的状态，否则，继续这个过程，直到leader被选举出来。 通过流程分析我们可以得出：要使Leader获得多数Server的支持，则Server总数必须是奇数2n+1，且存活的Server的数目不得少于n+1. 每个Server启动后都会重复以上流程。在恢复模式下，如果是刚从崩溃状态恢复的或者刚启动的server还会从磁盘快照中恢复数据和会话信息，zk会记录事务日志并定期进行快照，方便在恢复时进行状态恢复。

Fast LeaderElection 算法:

在选举过程中，某Server首先向所有Server提议自己成为leader，当其它Server收到提议以后，解决epoch和 zxid的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选出

2.5 ZK-同步流程

选完Leader以后，zk就进入状态同步过程。 

• Leader等待server(Follower+Observer)连接； 
• Follower连接leader，将最大的zxid发送给leader； 
• Leader根据follower的zxid确定同步点； 
• 完成同步后通知follower 已经成为uptodate状态； 
• Follower收到uptodate消息后，又可以重新接受client的请求进行服务了;

 2.6 ZK-工作流程

Leader主要功能:

• 恢复数据 
• 维持与Learner的心跳，接收Learner请求并判断Learner的请求消息类型
• Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理。

Follower主要功能

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