zookeeper学习笔记

简介

Apache zookeeper是apache Hadoop的子项目发展而来。是一个分布式的服务框架，主要用来解决分布式集群中应用系统的协调和一致性问题。

它能提供基于类似于文件系统的目录节点树方式的数据存储，但是 Zookeeper 并不是用来专门存储数据的，它的作用主要是用来维护和监控你存储的数据的状态变化。

简单的说，zookeeper=文件系统+通知机制。

使用场景

数据发布与订阅（配置中心）

发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等。

这类场景通常是这样：应用在启动的时候会主动来获取一次配置，同时，在节点上注册一个Watcher，这样一来，以后每次配置有更新的时候，都会实时通知到订阅的客户端，从来达到获取最新配置信息的目的。

注意：在上面提到的应用场景中，有个默认前提是：数据量很小，但是数据更新可能会比较快的场景。

负载均衡

通常同一个应用或同一个服务的提供方都会部署多份，达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑，其中比较典型的是消息中间件中的生产者，消费者负载均衡。

kafka就是是通过zookeeper来做到生产者、消费者的负载均衡。

命名服务

在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。被命名的实体通常可以是集群中的机器，提供的服务地址，远程对象等等——这些我们都可以统称他们为命名。

分布式服务框架Dubbo中使用ZooKeeper来作为其命名服务，维护全局的服务地址列表。在Dubbo实现中：
0. 服务提供者在启动的时候，向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入自己的URL地址。
0. 服务消费者启动的时候，订阅/dubbo/${serviceName}/providers目录下的提供者URL地址

注意：所有向ZK上注册的地址都是临时节点，这样就能够保证服务提供者和消费者能够自动感应资源的变化。

分布式通知/协调

利用ZooKeeper中的watcher通知机制，能够很好的实现分布式环境下不同系统之间的通知与协调，实现对数据变更的实时处理。使用方法通常是不同系统都对ZK上同一个znode进行注册，监听znode的变化，其中一个系统update了znode，那么另一个系统能够收到通知，并作出相应处理。

使用zookeeper来进行分布式通知和协调能够大大降低系统之间的耦合。

集群管理

利用ZooKeeper的两个特性，就可以实现一种集群机器存活性监控系统：

1. 监控系统在节点x上注册一个Watcher，那么如果x的子节点变化了，会通知该客户端。
2. 当增加机器时创建EPHEMERAL类型的节点，一旦客户端和服务器的会话结束，那么该节点就会消失。这样就知道节点可不用了。

这样替代监控系统使用ping的方式来感知集群中的机器是否在线

master选举

分布式系统中有时会需要用master来协调集群中的其他系统单元。利用zookeeper实现动态Master选举的办法：

要用到EPHEMERAL_SEQUENTIAL类型节点，多个客户端同时请求在ZK上创建节点，创建结果的一种可能情况是这样： /currentMaster/{sessionId}-1 ,/currentMaster/{sessionId}-2,/currentMaster/{sessionId}-3 ….. 每次选取序列号最小的那个机器作为Master，如果这个机器挂了，由于他创建的节点会马上消失，那么之后最小的那个机器就是Master了。

在Hbase中，也是使用ZooKeeper来实现动态HMaster的选举。在Hbase实现中，会在ZK上存储一些ROOT表的地址和HMaster的地址，Hbase的客户端查询数据时也是先连接到Zookeeper，因为Zookeeper里存放了ROOT表的位置信息。HRegionServer也会把自己以临时节点（Ephemeral）的方式注册到Zookeeper中，使得HMaster可以随时感知到各个HRegionServer的存活状态，同时，一旦HMaster出现问题，会重新选举出一个HMaster来运行，从而避免了HMaster的单点问题

分布式锁

• 独占锁（synchronize）
  
  • 创建锁：所有客户端都去创建/distribute_lock节点，最终成功创建的那个客户端也即拥有了这把锁。没有获取到锁的客户端注册watcher监听
  • 释放锁：获取锁的客户端删除/distribute_lock节点，其他客户端watcher监听到后再去竞争创建锁
• 共享锁 （读写锁）
  
  • 创建锁：在根节点下，读请求创建/R-01这样的子节点，写请求创建/W-01这样的子节点。
    
    • 读请求时，如果比自己序号小的节点中有写请求，那么进入等待，注册watcher监听，否则认为获取到锁；
    • 写请求时，如果自己不是序号最小的子节点，那么就需要进入等待，注册watcher监听，否则认为获取到锁；
  • 释放锁：删除自己创建的子节点

　分布式队列

就像是一个全是写操作的分布式共享锁，创建EPHEMERAL_SEQUENTIAL类型节点，如果自己不是序号号最小的子节点，那么进入等待，并向比自己序号小的最后一个节点注册watcher

基本概念

数据模型

树中的每个节点称为ZNode，它包含一个路径和与之相关的元数据，以及它的孩子节点。比较类似树形的文件系统，但Zookeeper的数据保存在内存中，所以拥有分布式同步服务的高吞吐和低延迟的特点。Zookeeper主要通过对树形数据结构ZNode节点的监听和变更来完成不同分布式环境中各个进程的协调和同步

• 节点ZNode可存储同步、协调相关的数据，数据量比较小
• ZNode中存有状态信息，包括版本号、ACL变更、时间戳等, 每次变更版本号都会递增。
• ZNode都有ACL，可以限制ZNode的访问权限
• 客户端可以在ZNode上设置Watcher监听，一但该ZNode有数据变更，就会通知客户端，触发回调方法。【Watcher都是一次性，触发一次后就失效，持续监听需要重新注册】
• 客户端和Zookeeper连接建立后就是一次session，Zookeeper支持临时节点（ephemeral node），它和一次session关联，一但session关闭，节点就被删除。

ZooKeeper节点类型

持久节点（PERSISTENT）

节点创建后，就一直存在，直到有删除操作来主动清除这个节点——不会因为创建该节点的客户端会话失效而消失。

持久顺序节点（PERSISTENT_SEQUENTIAL）

这类节点的基本特性和上面的节点类型是一致的。此外，在创建节点过程中，ZK会自动为节点名加上一个数字后缀，作为新的节点名。这个数字后缀的范围是整型的最大值。

临时节点（EPHEMERAL）

临时节点的生命周期和客户端会话绑定。如果创建了节点的客户端会话失效，那么这个节点就会自动被清除掉。注意，这里提到的是会话失效，而非连接断开。另外，在临时节点下面不能创建子节点。

临时顺序节点（EPHEMERAL_SEQUENTIAL）

以创建顺序加了序号的临时节点，可以用来实现分布式锁

Zookeeper集群

Zookeeper集群是由一组Server节点组成，这一组Server节点中存在一个角色为Leader的节点，其他节点都为Follower。客户端可以和集群中的任一Server建立连接，当读请求时，所有Server都可以直接返回结果；当请求为数据变更请求时，Follower会将请求转发给Leader节点，Leader节点接收到数据变更请求后，首先会将变更写入本地磁盘，以作恢复，当持久化完毕后才会将变更写入内存，并将变更后的数据同步到各个Follower。

Zookeeper集群中的角色

• Leader，负责进行投票的发起和决议，更新状态和数据
• Follower，用于接收客户端请求并向客户端返回结果，在选Leader时会进行投票