Zookeeper 理论基础

简介

        ZooKeeper 由雅虎研究院开发，后来捐赠给了 Apache。ZooKeeper 是一个开源的分布式应用程序协调服务器，其为分布式系统提供一致性服务。其一致性是通过基于 Paxos 算法的ZAB 协议完成的。其主要功能包括：配置维护、域名服务、分布式同步、集群管理等。

        zookeeper 的官网： http://zookeeper.apache.org

一致性

• 顺序一致性：zk 接收到的 N 多个事务请求（写操作请求），其会被严格按照接收顺序应用到 zk 中。
• 原子性：所有事务请求的结果在 zk 集群中每一台主机上的应用情况都是一致的。要么全部应用成功，要么全部失败。
• 单一视图：无论 Client 连接的是 zk 集群中的哪个主机，其看到的数据模型都是一致的。
• 可靠性：一旦 zk 成功应用了某事务，那么该事务所引发的 zk 状态变更会被一直保留下来，直到另一个事务将其修改。
• 最终一致性：一旦一个事务被成功应用，zk 可以保证在一个很短暂时间后，Client 最终能够从 zk 上读取到最新的数据状态。注意，不能保证实时读取到。
   

ZAB 协议简介

        ZAB ，Zookeeper Atomic Broadcast，zk 原子消息广播协议，是专为 ZooKeeper 设计的一种支持崩溃恢复的原子广播协议，在 Zookeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性。

        Zookeeper 使用一个单一主进程来接收并处理客户端的所有事务请求，即写请求。当服务器数据的状态发生变更后，集群采用 ZAB 原子广播协议，以事务提案 Proposal 的形式广播到所有的副本进程上。ZAB 协议能够保证一个全局的变更序列，即可以为每一个事务分配一个全局的递增编号 xid。当 Zookeeper 客户端连接到 Zookeeper 集群的一个节点后，若客户端提交的是读请求，那么当前节点就直接根据自己保存的数据对其进行响应；如果是写请求且当前节点不Leader，那么节点就会将该写请求转发给 Leader，Leader 会以提案的方式广播该写操作，只要有超过半数节点同意该写操作，则该写操作请求就会被提交。然后 Leader 会再次广播给所有订阅者，即 Learner，通知它们同步数据。

        ZAB 协议是 Paxos 算法的一种工业实现算法。但两者的设计目标不太一样。ZAB 协议主要用于构建一个高可用的分布式数据主从系统，即 Follower 是 Leader 的从机，Leader 挂了，马上就可以选举出一个新的 Leader，但平时它们都对外提供服务。而 Fast Paxos 算法则是用于构建一个分布式一致性状态机系统，确保系统中各个节点的状态都是一致的。

ZK的三类角色

        为了避免 Zookeeper 的单点问题，zk 也是以集群的形式出现的。zk 集群中的角色主要有以下三类：

• Leader：zk 集群中事务请求的唯一处理者；其也可以处理读请求。
• Follower：处理读请求；将事务请求转发给 Leader；对 Leader 发起的提案进行表决；同Leader 的事务处理结果；在 Leader 的选举过程中具有选举权与被选举权
• Observer：不具有表决权，且在 Leader 选举过程中没有选举权与被选举权的 Follower。

Learner：学习者，同步者。Learner = Follower + Observer

ZK三个重要数据

        在 ZAB 中有三个很重要的数据：

• zxid：64 位长度的 Long 类型，其高 32 位为 epoch，低 32 位为 xid。
• epoch：每一个新的 Leader 都会有一个新的 epoch
• xid：其为一个流水号

        这三个数据和zk的一致性算法息息相关，具体可以详细了解下ZK的一致性算法。

ZK三种模式

        ZAB 协议中对 zkServer 的状态描述有三种模式。这三种模式并没有十分明显的界线，它们相互交织在一起。

• 恢复模式：其包含两个重要阶段：Leader 的选举，与初始化同步
• 广播模式：其可以分为两类：初始化广播，与更新广播
• 同步模式：其可以分为两类：初始化同步，与更新同步

ZK四种状态

        zk 集群中的每一台主机，在不同的阶段会处于不同的状态。每一台主机具有四种状态。

• LOOKING：选举状态
• FOLLOWING：Follower 的正常工作状态
• OBSERVING：Observer 的正常工作状态
• LEADING：Leader 的正常工作状态