ZooKeeper学习笔记2

集群管理

Zookeeper 能够很容易的实现集群管理的功能，如有多台 Server 组成一个服务集群，那么必须要一个“总管”知道当前集群中每台机器的服务状态，一旦有机器不能提供服务，集群中其它集群必须知道，从而做出调整重新分配服务策略。同样当增加集群的服务能力时，就会增加一台或多台 Server，同样也必须让“总管”知道。

Zookeeper 不仅能够帮你维护当前的集群中机器的服务状态，而且能够帮你选出一个“总管”，让这个总管来管理集群，这就是 Zookeeper 的另一个功能 Leader Election。

它们的实现方式都是在 Zookeeper 上创建一个 EPHEMERAL 类型的目录节点，然后每个 Server 在它们创建目录节点的父目录节点上调用 getChildren(String path, boolean watch) 方法并设置 watch 为 true，由于是 EPHEMERAL 目录节点，当创建它的 Server 死去，这个目录节点也随之被删除，所以 Children 将会变化，这时 getChildren上的 Watch 将会被调用，所以其它 Server 就知道已经有某台 Server 死去了。新增 Server 也是同样的原理。

Q：是在server节点的上一层阶段创建EPHEMERAL 类型的目录节点？Watch是每个Server有一个还是总的用一个？

分布式集群是否存活监控. (每个节点启动后，注册一个EPHEMERAL节点到zookeeper中，注册一个Watcher获取EPHEMERAL节点的存在情况，消失即可代表集群节点dead)

Zookeeper 如何实现 Leader Election，也就是选出一个 Master Server。和前面的一样每台 Server 创建一个 EPHEMERAL 目录节点，不同的是它还是一个 SEQUENTIAL 目录节点，所以它是个 EPHEMERAL_SEQUENTIAL 目录节点。之所以它是 EPHEMERAL_SEQUENTIAL 目录节点，是因为我们可以给每台 Server 编号，我们可以选择当前是最小编号的 Server 为 Master，假如这个最小编号的 Server 死去，由于是 EPHEMERAL 节点，死去的 Server 对应的节点也被删除，所以当前的节点列表中又出现一个最小编号的节点，我们就选择这个节点为当前 Master。这样就实现了动态选择 Master，避免了传统意义上单 Master 容易出现单点故障的问题。

void findLeader() throws InterruptedException {
byte[] leader = null;
try {
leader = zk.getData(root + "/leader", true, null);
} catch (Exception e) {
logger.error(e);
}
if (leader != null) {
following();
} else {
String newLeader = null;
try {
byte[] localhost = InetAddress.getLocalHost().getAddress();
newLeader = zk.create(root + "/leader", localhost,
ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL);
} catch (Exception e) {
logger.error(e);
}
if (newLeader != null) {
leading();
} else {
mutex.wait();
}
}
}

共享锁（Locks）

共享锁在同一个进程中很容易实现，但是在跨进程或者在不同 Server 之间就不好实现了。Zookeeper 却很容易实现这个功能，实现方式也是需要获得锁的 Server 创建一个 EPHEMERAL_SEQUENTIAL 目录节点，然后调用 getChildren方法获取当前的目录节点列表中最小的目录节点是不是就是自己创建的目录节点，如果正是自己创建的，那么它就获得了这个锁，如果不是那么它就调用exists(String path, boolean watch) 方法并监控 Zookeeper 上目录节点列表的变化，一直到自己创建的节点是列表中最小编号的目录节点，从而获得锁，释放锁很简单，只要删除前面它自己所创建的目录节点就行了。

分布式lock (每个锁竞争者，排队时都在zookeeper中注册一个EPHEMERAL节点，排队过程中有节点dead了，zookeeper可以自动将其剔除队列，避免出现deadlock)

void getLock() throws KeeperException, InterruptedException{
List<String> list = zk.getChildren(root, false);
String[] nodes = list.toArray(new String[list.size()]);
Arrays.sort(nodes);
if(myZnode.equals(root+"/"+nodes[0])){
doAction();
}
else{
waitForLock(nodes[0]);
}
}
void waitForLock(String lower) throws InterruptedException, KeeperException {
Stat stat = zk.exists(root + "/" + lower,true);
if(stat != null){
mutex.wait();
}
else{
getLock();
}
}

队列

FIFO 队列用 Zookeeper 实现思路如下：

实现的思路也非常简单，就是在特定的目录下创建 SEQUENTIAL 类型的子目录 /queue_i，这样就能保证所有成员加入队列时都是有编号的，出队列时通过 getChildren( ) 方法可以返回当前所有的队列中的元素，然后消费其中最小的一个，这样就能保证 FIFO。

配置推送(Watcher)

zookeeper为解决数据的一致性，使用了Watcher的异步回调接口，将服务端znode的变化以事件的形式通知给客户端，主要是一种反向推送的机制，让客户端可以做出及时响应。比如及时更新后端的可用集群服务列表。（这里我们可以借鉴用来给网关推送目前可用的服务器列表）

persit机制

zookeeper中的persit机制主要是通过本地disk进行持久化，在本地disk上会有个memory数据对象保持同步。

持久化实现：

ZKDatabase

DataTree (内存树)

FileTxnSnapLog (disk持久化)

committedLog (FileTxnSnapLog的一份内存数据cache，默认存储500条变更记录)

zookeeper在新节点启动后，是否如何保证数据一致：

首先节点启动后，尝试读取本地的SnapShot log数据(zkDb.loadDataBase())，反序列化为DataTree对象，并获取last zxid。

follower启动后会向leader发送自己的last zxid

leader收到zxid后，对比自己当前的ZKDatabase中的last zxid
如果当前follower的zxid在内存committedLog中，直接将内存中的committedLog提取出来进行发送，否则将当前的DataTree直接发送给follower.(不再是发送变更记录)

数据同步完成后，follower会开始接收request请求

Zookeeper中是如何处理session的管理？ 因为用上了zookeeper，必然要考虑分布式常见的问题
比如：

zookeeper server挂了，对应的session是否会丢失?

zookeeper client发生了failover后(出现了Connection Loss异常)，对应的session是否会丢失?

解答：

在服务端，zookeeper中session的存储是有进行持久化的, 具体可见perist机制的描述。 一个新节点启动后，会从leader中同步对应的session数据

在客户端，zookeeper在每次出现failover后(出现了Connection Loss异常)，会重新带上sessionId,sessionPasswd发起一次链接请求。接收到该请求的server，会返回内存中的session信息