1. What is zookeeper?
zookeeper是apache基金的一个开源项目，致力于实现高可靠的分布式协调，提供服务解决分布式应用中的以下问题：
- 分布式应用的配置管理
- 集群管理
- 统一命名服务
- 分布式状态同步
2. 应用场景
2.1 分布式应用配置管理
2.2 分布式应用集群管理
Applicaion Server启动时与zookeepr建立会话创建EPHEMERAL节点，Applicaion Server停止时会话终止的时候，EPHEMERAL节点被删除。
2.3 分布式锁
核心依赖：利用zookeeper对znode节点操作的原子性
zookeeper分布式锁实现算法:
- 调用 create( )，参数 pathname 为 "locknode/lock-"，并设置 sequence 和 ephemeral 标志。
- 在所节点（lock node）上调用 getChildren( ) ，不需要设置监视标志。
- 如果在第 1 步中创建的节点的路径具有最小的序号后缀，那么该客户端就获得了锁。
- 客户端调用 exists( ) ，并在锁目录路径中前一个最小序号的节点上设置监视标志。
- 如果 exists( ) 返回 false，跳转至第 2 步，否则，在跳转至第 2 步之前等待前一步路径上节点的通知消息。
示例：多个进程互斥访问某个文件
2.4 其它场景
- Barriers
- Queues
- Leader Election
- Two-phased Commit
3. zookeeper overview
3.1 zookeeper数据模型和层次命名空间
zookeeper本质上是通过一个类似标准文件系统的共享层次命名空间来实现分布式进程间的协调，其中命名空间节点被称作znode，znode节点可以包含数据和孩子节点，和标准文件系统不一样的是zookeeper把数据保存在内存当中，因为在内存中读写数据，所以zookeeper可以保证高吞吐和低延时性。
znode节点的Stat结构体由字段：
- czxid：创建节点的zxid
- mzxid：对znode最近修改的zxid
- pzxid：对znode节点孩子节点最近修改的zxid
- ctime：以距离时间原点(epoch)的毫秒数表示的znode创建时间
- mtime：以距离时间原点(epoch)的毫秒数表示的znode最近修改时间
- version：znode数据的修改次数
- cversion：znode子节点修改次数
- aversion：znode的ACL修改次数
- ephemeralOwner：如果znode是临时节点，则指示节点所有者的会话ID；如果不是临时节点，则为零
- dataLength：znode数据长度
- numChildren：znode子节点个数
两种特殊zode:
- Ephemeral Nodes
Ephemeral节点在创建它的会话活动期间存在。会话终止的时候，临时节点被删除，所以临时节点不能有子节点。(应用：集群管理)
- Sequence Nodes
创建znode时，可以要求ZooKeeper在路径名后增加一个单调增加的计数器部分。这个计数器相对于znode的父节点是唯一的。计数器的格式是%010d，例如：<path>0000000001。(应用：分布式锁，选举)
znode节点监听：Watches
客户端可以在znode上设置Watch。对znode的修改将触发Watch，然后移除观Watch。Watch被触发时，ZooKeeper向客户端发送一个事件通知。
znode访问控制ACL
znode节点通过 Access Control List (ACL) 控制节点访问权限
3.2 zookeeper集群
zookeeper一般是以集群方式提供服务的，集群中的server互相知道彼此存在，只要集群中一半以上的server处于可用状态，整个zookeeper服务就处于可用状态(因此zookeepr server数一般为2n＋1)。zookeeper集群中的server通过选举确定一个leader，其余为follower。
-
为什么需要leader？
leader作用:解决分布式环境中的一致性问题。zookeeper集群中存在多个server节点，每个节点都能接收处理请求，设想来自两个客户端client1和client2的两个并发请求分别被zookeeper中的server1和server2接收，两个请求设置同一个znode节点数据，client1请求设置该znode节点为a，client1请求设置该znode节点为b，那么最后该znode节点数据是a还是b，leader进行决策。
leader如何选举?
leader默认选举算法:FastLeaderElection
- Leader竞选规则－sid更大（配置）、持有的数据更新(zxid更新)则更可能为leader
- 选举开始时每一个节点都推荐自己为leader(广播到所有节点)
- 选举过程中接收到更合适推荐人(sid,zxid更大)则更改推荐人(广播到所有节点)
- 大部分人意见一致时，结束选举。
示例：假设有3个节点A/B/C，其都还没有数据，按照sid关系为C>B>A,图中，v(A)表示当前推荐人为A；r[]表示收到的投票集合
3.3 zookeeper配置
zoo.cfg
tickTime=2000
initLimit=10
syncLimit=5
dataDir=/root/fmm/data/zookeeper
clientPort=2181
server.1=10.20.20.76:2887:3887
server.2=10.20.20.239:2887:3887
server.3=10.20.21.27:2887:3887
参数说明：
- tickTime 基本时间单元，以毫秒为单位，代表一次心跳时间
- dataDir 数据目录
- clientPort 客户端链接zookeeper端口
- initLimit 设定了允许所有跟随者与领导者进行连接并同步的时间，如果在设定的时间段内，半数以上的跟随者未能完成同步，领导者便会宣布放弃领导地位，进行另一次的领导选举。如果zk集群环境数量确实很大，同步数据的时间会变长，因此这种情况下可以适当调大该参数。
- syncLimit 设定了允许一个跟随者与一个领导者进行同步的时间，如果在设定的时间段内，跟随者未完成同步，它将会被集群丢弃。所有关联到这个跟随者的客户端将连接到另外一个跟随着。
- server.X=A:B:C 其中X是一个数字, 表示这是第几号server. A是该server所在的IP地址. B配置该server和集群中的leader交换消息所使用的端口. C配置选举leader时所使用的端口.
3.4 zookeeper session
客户端使用某种语言绑定创建一个到服务的句柄时，就建立了一个ZooKeeper会话。会话创建后，句柄处于CONNECTING状态，客户端库会试图连接到组成ZooKeeper服务的某个服务器；连接成功则进入到CONNECTED状态。通常操作中句柄将处于这两个状态之一。如果发生不可恢复的错误，如会话过期、身份鉴定失败，或者应用显式关闭，则句柄进入到CLOSED状态。下图显式了ZooKeeper客户端可能的状态转换：
3.5 zookeeper api
zookeeper提供一组很简单的程序接口，它仅支持下面这些操作：
- create：creates a node at a location in the tree
- delete：deletes a node
- exists：tests if a node exists at a location
- get data：reads the data from a node
- set data：writes data to a node
- get children：retrieves a list of children of a node
- sync：waits for data to be propagated
3.6 zookeeper Guarantees
- 顺序一致性：客户端的更新请求被按照放送顺序处理
- 原子性：更新结果要么是成功要么是失败，没有其它可能性
- 单系统镜像：客户端不管连接到哪台服务器看到的结果都是一样的
- 可靠性：数据一旦被更新将会被持久化直到再次被更新
- 实时性：客户端能在确定的时间范围内获得响应
4.zookeeper应用实践－pafa5在线管控平台
fsg_webii工程举例：
- fsg_webii应用启动时pafa5中间件启动和zookeeper建立会话，并且对papp配置文件(fsg_webii.properties)设置watch
- pafa5中间件根据fsg_webii.properties文件内容创建spring容器加载lib(包括sar和lib)
- 配置文件，jar包，zip包通过pafa5管控平台上传到zookeeper
- fsg_webii.properties改变zookeeper发送watch事件通知pafa5中间件
- pafa5中间件收到watch事件从zookeepr重新加载fsg_webii.properties，如果fsg_webii.properties中papp.status=stop,pafa5中间件关闭spring容器，如果fsg_webii.properties中papp.status=running，pafa5中间件重新创建spring容器加载lib(包括sar和lib)
