Zookeeper

Zookeeper是一个开源代码分布式协调服务，它包含一个简单的原语集。分布式应用程序可以基于它来实现同步服务、配置维护、命名服务等。

1 Zookeeper的基本概念

1.1 角色

zookeeper中的角色主要有以下三类，如下表所示：

系统模型如图所示：

1.2 Zookeeper节点（znode）

1.临时节点、临时有序节点：临时节点只能存在一次会话中，当session失效时，改节点将自动删除。临时节点无法创建子节点。临时有序节点 0000000…1、0000000….2
临时节点可实现：Master选举、分布式锁等

2.普通节点、有序节点：普通节点及有序节点为永久存在，除非主动删除此节点。

1.3 Zookeeper目的

1.最终一致性：客户端连接时，展示给它都是同一个视图，这是zookeeper最重要的性能。

2.可靠性：具有简单、健壮、良好的性能，数据被一台服务器接受，那么将被所有的服务节点接受。

3.实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。

4.等待无关：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。

5.原子性：要么成功，要么失败。

6.顺序性：包括全局有序和偏序两种：如果消息a在消息b之前发送，则所有Server应该看到相同的结果。；偏序是如果消息a在消息b之前发生（a导致了b），并被一起发送，则a始终在b之前被执行。

2 ZooKeeper的工作原理

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。

每个Server在工作过程中有三种状态：

LOOKING：当前Server不知道leader是谁，正在搜寻

LEADING：当前Server即为选举出来的leader

FOLLOWING：leader已经选举出来，当前Server与之同步

2.1 选主流程

当leader崩溃或失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的Server都恢复到一个正确的状态。Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。

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

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

1.leader等待server连接；

2.Follower连接leader，将最大的zxid发送给leader；

3.Leader根据follower的zxid确定同步点；

4.完成同步后通知follower 已经成为uptodate状态；

5.Follower收到uptodate消息后，可以重新接受客户端的请求进行服务了。

2.2 Leader工作流程

Leader主要有三个功能：

1 .恢复数据；

2 .维持与Learner的心跳，接收Learner请求并判断Learner的请求消息类型；

3 .Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理。

PING消息是指Learner的心跳信息；REQUEST消息是Follower发送的提议信息，包括写请求及同步请求；ACK消息是Follower的对提议的回复，超过半数的Follower通过，则commit该提议；REVALIDATE消息是用来延长SESSION有效时间。

2.3 Follower工作流程

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结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新。

2.4 ZAB原理：

1. Atomic Broadcast

同一时刻存在一个Leader节点，其他节点称为“Follower”，如果是更新请求，如果客户端连接到Leader节点，则由Leader节点执行其请求；如果连接到Follower节点，则需转发请求到Leader节点执行。但对读请求，Client可以直接从Follower上读取数据，如果需要读到最新数据，则需要从Leader节点进行。

2.Leader Election

Leader选举主要是依赖Paxos算法，具体算法过程请参考其他博文，这里仅考虑Leader选举带来的一些问题。Leader选举遇到的最大问题是，”新老交互“的问题，新Leader是否要继续老Leader的状态。这里要按老Leader Crash的时机点分几种情况：
老Leader在COMMIT前Crash（已经提交到本地）
老Leader在COMMIT后Crash，但有部分Follower接收到了Commit请求

第一种情况，这些数据只有老Leader有，当老Leader重启后，需要与新Leader同步并把这些数据从本地删除，以维持状态一致。

第二种情况，新Leader应该能通过一个多数派获得老Leader提交的最新数据
老Leader重启后，可能还会认为自己是Leader，可能会继续发送未完成的请求，从而造成类似与脑裂问题。所以通过zxid来解决这种情况。
zxid为一64位数字，高32位为leader信息又称为epoch，每次leader转换时递增；低32位为消息编号，Leader转换时应该从0重新开始编号。
通过zxid，Follower能很容易发现请求是否来自老Leader，拒绝老Leader的请求。

Zookeeper文档：http://zookeeper.apache.org/doc/trunk