双鱼座小龙

zookeeper集群部署监控与选举同步流程等工作原理

部署一个zookeeper集群，要多简单就能有多简单（下载压缩包，解压，修改配置文件zoo.cfg,执行启动脚本），但是想要真的把这套东西玩好了，还是需要费些功夫研究一番的。就跟自己搭建一个lnmp的站点，仅仅搭建，网上有各种教程和专门的一键安装包，但是部署后，根据实际场景需求和系统负载进行配置优化时，我们就需要了解一些与lnmp相关的知识了。

目前，我们业务应用是通过配置中心集中管理应用各种配置的，管理中心应用到了zookeeper集群推送配置信息，研究下zookeeper的leader选举，数据更新同步的知识还是有收获的。

zookeeper集群主要用来解决分布式集群中应用系统的一致性问题，应用场景目前接触到的主要就是两种：同步锁和配置管理。

zookeeper集群的部署：

环境：

操作系统版本：lsb_release -a

Description: CentOS release 6.3 (Final)

Linux zookeeper01.nh 2.6.32-279.el6.x86_64 x86_64 x86_64 x86_64 GNU/Linux

zookeeper版本：zookeeper-3.4.5

配置文件：

目录：/data/webapps/zookeeper/conf

配置详情：

less zoo.cfg
# The number of milliseconds of each tick
tickTime=2000
#CS通信心跳数，服务器之间或客户端与服务器之间间隔多久发送一个心跳
#tickTime以毫秒为单位。
# The number of ticks that the initial
# synchronization phase can take
initLimit=10
#initLimit：Leader与Follower初始通信时限
#集群中的follower服务器(F)与leader服务器(L)之间初始连接时能容忍的最多心跳数（tickTime的数量）。
# The number of ticks that can pass between
# sending a request and getting an acknowledgement
syncLimit=5
#syncLimit：Leader与Follower同步通信时限
#集群中的follower服务器与leader服务器之间请求和应答之间能容忍的最多心跳数（tickTime的数量）。
# 3.4.0 版本后引入了数据自动清理功能
autopurge.purgeInterval=1 (zookeeper自动清理间隔，单位小时)
autopurge.snapRetainCount=10 （保留快照文件个数）
# the directory where the snapshot is stored.
dataDir=/data/appdatas/zookeeper
Zookeeper保存数据的目录，默认情况下，Zookeeper将写数据的日志文件也保存在这个目录里。
#commitLog数据存储
dataLogDir=/data/applogs/zookeeper
Zookeeper保存日志文件的目录。
# the port at which the clients will connect
clientPort=2181
#客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。
# znode
#zookeeper 集群信息（服务器编号，服务器地址，Leader与Follower通信端口，选举端口）
#选举端口，表示选举新leader时服务器间相互通信的端口（当leader挂掉时，其余服务器会相互通信，选择出新的leader）
server.1（myid文件，dataDir目录中）=101.1.2.132:2888:3888
#servers making up the ZooKeeper ensemble. When the server starts up, it determines which server it is by looking for the file myid in the data directory. That file contains the server number, in ASCII, and it should match x in server.x in the left hand side of this setting.
server.2=101.1.2.137:2888:3888
server.3=101.1.2.162:2888:3888
server.4=101.1.2.167:2888:3888
server.5=101.1.2.158:2888:3888

详细配置说明参看：

https://zookeeper.apache.org/doc/trunk/zookeeperAdmin.html#sc_advancedConfiguration

保证zookeeper持续提供服务

daemontools ：

http://cr.yp.to/daemontools.html

安装方法：

http://cr.yp.to/daemontools/install.html

mkdir -p /package

chmod 1755 /package

cd /package

wget http://cr.yp.to/daemontools/daemontools-0.76.tar.gz

tar -zxvf daemontools-0.76.tar.gz

cd admin/daemontools-0.76

package/install

创建目录：/service/zookeeper

# 创建文件 run

#!/bin/bash
. /etc/profile
exec 2>&1
exec /data/webapps/zookeeper/bin/zkServer.sh start-foreground

启动：

supervise zookeeper &

supervise就会在后台监控zookeeper的进程，如果zookeeper进程被意外关闭，supervise进程会立即执行run文件中的命令，重启启动zookeeper。

zookeeper监控：

taokeeper, ZooKeeper-Monitor, a monitor for zookeeper in java

官方地址：

https://github.com/alibaba/taokeeper

http://jm-blog.aliapp.com/?p=1450

taokeeper相关截图：

zabbix相关模版截图：

zabbix agent相关检测配置：

UserParameter=zk_version, echo stat | nc 127.0.0.1 2181 |grep version | awk -F ":" '{print $2}'

UserParameter=zk_received, echo stat | nc 127.0.0.1 2181 |grep Received | awk -F ":" '{print $2}'

UserParameter=zk_sent, echo stat | nc 127.0.0.1 2181 |grep Sent | awk -F ":" '{print $2}'

UserParameter=zk_mode, echo stat | nc 127.0.0.1 2181 |grep Mode | awk -F ":" '{print $2}'

UserParameter=zk_nodecount, echo stat | nc 127.0.0.1 2181 |grep 'Node count'| awk -F ":" '{print $2}'

UserParameter=zk_clientscount, echo cons | nc 127.0.0.1 2181 |grep -v '127.0.0.1' |wc -l

UserParameter=zk_status, echo ruok | nc 127.0.0.1 2181

UserParameter=zk_aclient, echo cons | nc 127.0.0.1 2181 |grep -v 127.0.0.1 |awk -F: '{print $1}'|awk -F/ '{print $2}'|head -n1

zookeeper工作原理：

ZooKeeper是一开源分布式应用程序协调服务，包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等功能，可提供一种可靠的、可扩展的、分布式的、可配置的协调机制来统一系统的状态。

zookeeper的基本概念

角色

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

Leader，"Learner"(Follower,Observer),client

系统模型如图所示：

设计目的

1.最终一致性：client不论连接到哪个Server，展示给它都是同一个视图。

2 .可靠性：具有简单、健壮、良好的性能，如果消息m被到一台服务器接受，那么它将被所有的服务器接受。

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

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

5.原子性：更新只能成功或者失败，没有中间状态。

6 .顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。

数据模型：

Zookeeper 会维护一个具有层次关系的数据结构，它非常类似于一个标准的文件系统。

Zookeeper 数据结构有如下这些特点：

每个子目录项如 NameService 都被称作为 znode，这个 znode 是被它所在的路径唯一标识，如 Server1 这个 znode 的标识为 /NameService/Server1
znode 可以有子节点目录，并且每个 znode 可以存储数据，注意 EPHEMERAL 类型的目录节点不能有子节点目录
znode 是有版本的，每个 znode 中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据
znode 可以是临时节点，一旦创建这个 znode 的客户端与服务器失去联系，这个 znode 也将自动删除，Zookeeper 的客户端和服务器通信采用长连接方式，每个客户端和服务器通过心跳来保持连接，这个连接状态称为 session，如果 znode 是临时节点，这个 session 失效，znode 也就删除了
znode 的目录名可以自动编号，如 App1 已经存在，再创建的话，将会自动命名为 App2
znode 可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端

工作原理

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与之同步

Leader选举流程：

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

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

zookeeper数据同步过程：

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

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

流程图如下所示：

工作流程

Leader工作流程

Leader主要有三个功能：

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

PING消息是指Learner的心跳信息；REQUEST消息是Follower发送的提议信息，包括写请求及同步请求；ACK消息是Follower的对提议的回复，超过半数的Follower通过，则commit该提议；REVALIDATE消息是用来延长SESSION有效时间。
Leader的工作流程简图如下所示，在实际实现中，流程要比下图复杂得多，启动了三个线程来实现功能。

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

Follower的工作流程简图如下所示，在实际实现中，Follower是通过5个线程来实现功能的。

observer流程和Follower的唯一不同的地方就是observer不会参加leader发起的投票。

学习参考：

http://www.ibm.com/developerworks/cn/opensource/os-cn-zookeeper/