zookeeper学习笔记

以下是再次泛读《从Paxos到Zookeeper分布式一致性原理与实践》的一些记录。

Zookeeper是一种实现了分布式数据的一致性的解决方案。可以实现诸如数据发布/订阅、负载均衡、命名服务、集群管理等，许多开源项目都基于zookeeper实现集群的管理，数据的同步等，如用于海量数据存储分析的Hadoop，实时计算框架Storm，高吞吐量的消息队列kafka等。

关于zookeeper的一些概念：
1.zookeeper集群的角色
在集群中各个角色主要由leader、follower和observer，leader由整个集群选取产生，负责提供对外的读写服务；follower和observer会参与数据的同步，和leader一起保证整个集群的高可用性，但是observer不会参与leader的选举,observer会将客户端的写请求转给leader，其存在的目的是为了拓展系统，提高读取速度。

2.数据节点（Znode）
这里的数据节点主要反映的是zookeeper的数据模型中的数据单元。zookeeper将所有数据存储在内存中，数据模型是一棵树，由’/’分割的路径就是Znode，例如’/test/jack’,’/test/lucy’,是两条路径，而’/test’、’/jack’以及’/lucy’就是Znode。zookeeper中像’/test/jack’这样的路径是不能递归创建的，需要一级级的创建。Znode的类型由以下几种：

• 持久型：一旦创建就会一直留在服务器上，直到主动删除；
• 临时型：其生命周期和一次会话的生命周期绑定在一起，会话失效会被自动清理；
• 顺序型（和持久/顺序搭配使用）：每个节点的创建会有一个先后顺序，反映在成功创建节点后的节点名字上
• 以上的合理组合：持久顺序型，临时顺序型

3.会话（session）
客户端要想和zookeeper集群通信，双方之间必须建立一个TCP连接，会话的生命周期就是从这个TCP连接成功建立后开始的。会话保存着客户端和服务器的连接状态、临时节点的生命周期、请求的执行顺序等。临时节点的生命周期会随着会话的结束而终结，请求的执行顺序会反映到zookeeper的日志和快照中，同样影响着集群的恢复重建，leader选举等。

4.版本
每个znode的数据都会有一个叫做Stat的数据结构，Stat中的数据结构会有三个版本：version,cversion,aversion。版本号反映的是节点对于属性的变更次数。stat的结构如下：
xxxxx //保存节点的数据内容
cZxid = 0x316
ctime = Sun Feb 26 10:44:38 CST 2017
mZxid = 0x316
mtime = Sun Feb 26 10:44:38 CST 2017
pZxid = 0x316
cversion = 0 //当前znode子节点的版本号
dataVersion = 0 //数据节点版本号，可以用于乐观锁的写入校验
aclVersion = 0 ///节点ACL版本号
ephemeralOwner = 0x15a784d6e5f0001
dataLength = 153
numChildren = 0

5.Watcher
客户端已在指定的节点上注册一个监听事件(Watcher)，当节点内容发生变化时，监听事件会被触发，客户端会收到相应的通知。Watcher是一次性触发事件，对于同一个节点的Wacther在被第一次触发后，除非客户端再次对其进行监视，否则不会再收到事件通知。监听事件被触发后，客户端收到的仅仅是对该事件的通知，客户端需要主动会获取该节点发生变化的具体内容等。

6.ACL
ACL(Access Control Lists)提供了对于节点的一种更细粒度的权限控制。zookeeper提供的5中权限为CREATE,READ,WRITE,DELETE,ADMIN。ACL的权限模式也可标识为”scheme:id:permission”，scheme用来确定权限验证过程中使用的检验策略，scheme可以为IP/Digest/World/Super，id是赋予权限的对象，permission就是上述的五种权限。

7.ZAB协议
ZAB(Zookeeper Atomic Broadcast,zookeeper原子广播协议)，是zookeeper实现分布式一致性的核心算法。ZAB包括崩溃恢复和消息广播两个基本模式。崩溃恢复用于集群出现网络中断，崩溃退出等异常情况时的数据一致性恢复和leader选举。消息广播，对于客户端的请求，leader会将其生成事务，发送给集群中的其他机器进行投票和提交等。

8.服务端地址列表
客户端在连接zookeeper时，需要传入服务端的地址，zookeeper允许用户传入一个地址“列表”，形如：HOST1:PORT1,HOST2:PORT2,HOST3:PORT3。但是实际上zookeeper只会选取其中一个zookeeper服务来和客户端通信。在实际中，会先将该服务器地址列表打乱，然后拼成一个“环形”队列，每次从队列中返回一个可用的服务端地址。

9.事务日志和快照
zookeeper通过事务日志和快照来提供数据的备份以及灾后恢复。事务日志是将每次对zookeeper的事务操作以日志的形式存储到磁盘。快照是将全量备份zookeeper服务器上内存中的数据，并将其写到指定的磁盘文件中。事务日志的存储路径可以通过dataLogDir来配置，默认和快照文件的路径一致；快照的路径为dataDir所指定路径。数据的恢复可以通过解析快照文件来实现，因为快照中保存的是某一时刻的全量数据，会依次解析获取到的最新快照文件（最多100个），当某一最新的快照文件可用时，其后的快照文件不会继续解析。快照文件有可能和服务器最后宕机时仍有一些“差距”，这可以通过事务日志进行差异化同步。

Zookeeper集群的配置与搭建
确认已经安装了jdk环境
下载安装包（https://zookeeper.apache.org/releases.html#download）

tar -zxvf zookeeper-3.4.8.tar.gz //解压ln -sf zookeeper-3.4.8 zookeeper //建立软连接

1.配置zoo.cfg

cd zookeeper/confcp zoo_sample.cfg zoo.cfg修改 zoo.cfg//主要配置如下：tickTime=2000 //zookeeper中的最小时间单元的长度initLimit=10  //leader服务器等待follower启动并完成数据同步的时长，时长为10个tickTimesyncLimit=5   //leader服务器等待follower之间心跳检测的最大时长，时长为5个tickTimedataDir=/home/zookeeper/data  //dataDir用于保存zookeeper的快照文件，此外如果不设置dataLogDir，默认会将日志文件也保存到该目录下clientPort=2181 //zookeeper对外服务端口autopurge.snapRetainCount=3 //配置只保存最近的3个快照数据autopurge.purgeInterval=1   //快照清理的间隔，单位小时//zookeeper集群的机器列表，格式为server.id=ip:port1:port2//id是服务器在集群中的编号,ip是服务器的地址，port1是follower和leader的通信以及同步端口，port2是选举leader的端口,//如果只是单台机器，那么只要配置本机的编号(如1)及IP地址server.1=[ip]:2888:3888 //如果是由不同机器组成的集群，那么要配上所有的机器server.1=[ip1]:2888:3888server.2=[ip2]:2888:3888  ...

2.创建myid文件
在zoo.cfg配置的dataDir目录下创建名为myid的文件，内容为本台机器在集群中的编号

3.启动zookeeper服务
zookeeper/bin/zkServer.sh start
通过zkServer.sh status以及jps 查看是否有QuorumPeerMain进程来验证服务的启动状况

4.如果是使用不同机器搭建的集群，每台机器的配置都可以参考上述；当然也可以在同一台机器上，使用不同的端口，来模拟集群，
这时要修改配置中的clientPort=2181，server.id=ip:port1:port2中的port1，port2，以及dataDir目录等。

---

1.倪超.从Paxos到Zookeeper分布式一致性原理与实践.电子工业出版社,2015.