内容不涉及算法相关内容,paxos算法,zab协议等网络上已经有很多优秀的文章,这里就不献丑了
什么是Zookeeper
ZooKeeper是分布式应用程序的分布式协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、集群管理等
为什么需要zookeeper
随着业务发展,单机系统处理能力达到上限,就需要对系统进行扩展,假设我们需要将数据库扩展为主从结构,客户端需要知道数据库节点中主节点的位置,而当主节点发生故障时我们需要将从节点设置为新的主节点,就像redis一样,类似的场景有很多; 而在分布式系统中,需要协调的信息很多,比如某个服务的地址,状态,服务的名称,或是集群间状态同步等等......
若不使用zookeeper:
解决办法也简单,比如使用一个map来存储相关的信息,需要访问的时候从内存中取出即可,但由于信息可能需要在不同机器的进程中共享,还需要编写socket通讯,另一方面这样的方式存在单点故障,如果存储信息的服务器宕机,整个系统全部瘫痪;
为了解决单点故障,需要将这个存储信息的服务设计为分布式的;但是这又产生了新的问题,数据如何在分布式系统中保持一致?
这就需要一致性算法Paxos来保证,而由于Paxos存在活锁问题zookeeper使用ZAB协议来同步数据,并保证了一致性;
zookeeper为我们实现了上述的数据存储,分布式服务,高可用性等基础功能,利用zookeeper可以很方便的协调分布式应用程序;
使用场景
zookeeper的使用场景比较多,以下例举其最常用的场景
服务注册/订阅
在分布式服务中,通常都需要使用统一的命名,即将一些复杂不方便记忆,容易出错的信息对应到一个唯一的简洁的名称,zookeeper可以很容易实现名称的唯一性,并在这个唯一的名称下存储一些数据;在访问提供方启动后将信息放到zookeeper中,客户端通过相同的服务名称从zookeeper订阅需要的服务名称,从而获取服务提供方的信息
配置管理(Configuration Management)
在分布式系统中经常有某些服务的调用非常频繁,由于单点压力大所以将其部署为集群,当需要对这个服务的配置进行修改时,以往需要逐个修改,效率低且容易出错,得益于zookeeper提供的watch(监视)机制可以实现集中式配置管理,当配置发生变化zookeeper可以通知所有节点,这样节点就可以访问zookeeper获取并应用最新的配置;
组管理(Group Management)
当需要自己搭建主从结构时,需要能够选举出master,同时当slave上线或是下线时master能够立即感知(利用临时顺序节点,选取最小作为master);当master宕机后,slave要选出新的master,并通知其他slave(利用watch机制实现)
分布式锁(Distribution Lock)
在同一台机器实现互斥锁是比较简单的,因为线程或进程之间可以直接利用内存或文件进行状态的同步,但是在分布式环境中,进程运行在不同的计算节点上,无法像单机那样直接通过内存同步,利用zookeeper的watch,多个进程可以监视同一个数据(代表锁),当数据状态发生变化时进程可以知道当前锁的状态;
zookeeper的特性
高可用
ZooKeeper已实现主从复制。像它协调的分布式进程一样，ZooKeeper本身也可以在一组主机上进行主从复制。从而避免单点故障并提高性能；
组成ZooKeeper集群的服务器都彼此了解。它们共同维护内存中的数据，以及持久存储中的事务日志和快照。只要及群众大多数服务器可用，ZooKeeper服务将可用。
客户端连接到单个ZooKeeper服务器。客户端维护一个TCP连接，通过它发送请求，获取响应，获取监视事件并发送心跳检测。如果与服务器的TCP连接断开，客户端将连接到其他服务器。
高性能
在“读取为主”的工作负载中，zookeeper非常快。ZooKeeper应用程序可在数千台计算机上运行，并且在读取比写入更为常见的情况下，其性能最佳，比率约为10：1。
提供的保证
- 顺序一致性-来自客户端的更新将按照其发送顺序进行处理。
- 原子性-更新成功或失败。不会产生部分结果。
- 单个数据视图-无论客户端连接到哪个服务器，客户端都将看到相同的数据视图。也就是说，即使客户端故障转移到具有相同会话的其他服务器，客户端也永远不会看到系统的较旧数据。(一致性体现)
- 可靠性-数据被更新后，此更新将一直持续到客户端重新覆盖更新为止，否则将永久生效
- 及时性-确保系统的客户看到的数据在特定时间范围内是最新的。（最终一致性）
zookeeper的相关概念
1.节点znode
Zookeeper会保存任务的分配、完成情况，等共享信息，那么ZooKeeper是如何保存的呢?在 ZooKeeper中，这些信息被保存在一个个数据节点上，这些节点被称为znode。它采用了类似文件系统 的层级树状结构进行管理。见下图示例:
根节点/包含4个子节点，其中三个拥有下一级节点。有的叶子节点存储了信息。 节点上没有存储数据，也有着重要的含义。比如在主从模式中，当/master节点没有数据时，代表分布式应用的主节点还没有选举出来。
znode节点存储的数据为字节数组bytes。存储数据的格式zookeeper不做限制，也不提供解析，需要应用自 己实现。
持久节点
持久节点只能通过delete删除。zookeeper会将操作以日志的形式写入到磁盘,当日志变大时，会将所有znodes当前状态的快照写入文件系统，并生成新的事务日志文件;当zookeeper启动时将从日志恢复数据;
临时节点
临时节点在创建该节点的客户端崩溃或关闭时，自动被删除。在当前版本，由于临时znode会因为创建者会话过期被删 除，所以不允许临时节点拥有子节点。
前面 例子中的/master应该使用临时节点，这样当主节点失效或者退出时，该znode被删除，其他节点 知道主节点崩溃了，开始进行选举的逻辑。另外/works/worker-1也应该是临时节点，在此从节点 失效的时候，该临时节点自动删除。
节点版本
Znodes还维护一个数据结构，其中包括用于数据更改，ACL(访问控制列表)更改和时间戳的版本号，znode的数据每次更改时，版本号都会增加。例如，每当客户端检索数据时，会接收数据的版本。当客户端发起写入操作时则需提供与服务器上一致的版本号,否则将更新失败;
每个znode上的数据都被原子地读取和写入。读取操作将获取与znode关联的所有数据，而写入将替换所有数据。每个节点都有一个访问控制列表（ACL），用于限制谁可以执行操作。
有序节点
znode可以被设置为有序(sequential)节点。有序znode节点被分配唯一一个单调递增的序号。 序号的格式为％010d，即10位数字，不足的填充为0，零如果创建了个一有序节点为/workers/worker-，zookeeper会自动分配一个序号1，追加在名字后面，znode名称为/workers/worker-0000000001。通过这种方式，可以创建唯一名称znode，并且可以直观 的看到创建的顺序。
znode常见操作及暴露的API:
- ls /path 查看节点的所有子节点
- create /path data :创建一个名为/path的znode，数据为data。
- -e 临时节点(当前客户端关闭后/或当前节点重启后失效)
- -s 有序节点(在节点名称后面添加节点自增的序号)
- set /path data :设置名为/path的znode的数据为data
- get /path :返回名为/path的znode的数据、
API
- delete：删除节点
- exists：测试某个位置是否存在节点
- get children ：获取节点子节点的列表
- sync：等待数据在所用节点完成同步
注意：上述列出的指令部分用于zkCli部分用于javaAPI;
2.观察与通知（watch）
分布式应用需要及时知道zookeeper中znode的变化，从而了解到分布式应用整体的状况，如果采用轮 询方式，代价太大，绝大多数查询都是无效的。因此，zookeeper采用了通知的机制。客户端向 zookeeper请求，在特定的znode设置观察点(watcher)。Watcher是Zookeeper中的一个很重要的 特性。Zookeeper允许用户在指定节点上注册一些Watcher，并且在一些特定事件触发的时候， ZooKeeper服务端会将事件通知到感兴趣的客户端上去，该机制是Zookeeper实现分布式协调服务的重要支撑。、
wtahc的主要特性：
- 当监听器监听的事件被触发,服务端会发送通知给客户端,但通知信息中不包括事件的具体内容。以监听ZNode结点数据变化为例,当Znode的数据被改变,客户端会收到事件类型为 NodeDataChanged的通知,但该Znode的数据改变成了什么客户端无法从通知中获取,需要客户端 在收到通知后手动去获取。
- Watcher是一次性的。一旦被触发将会失效。
- 3.6.0中的新增功：客户端可以在znode上设置永久性的监视，这些监视在触发时不会删除，并且会以递归方式触发注册znode以及所有子znode的通知。