Zookeeper是基于观察者模式的分布式服务管理框架。

  Zookeeper 作为一个分布式的服务框架主要用来解决分布式集群中应用系统的一致性问题。ZooKeeper提供的服务包括分布式消息同步和协调机制、服务器节点动态上下线、统一配置管理、负载均衡、集群管理等。

  ZooKeeper提供基于类似于Linux文件系统的目录节点树方式的数据存储即分层命名空间。Zookeeper 并不是用来专门存储数据的它的作用主要是用来维护和监控你存储的数据的状态变化通过监控这些数据状态的变化从而可以达到基于数据的集群管理ZooKeeper节点的数据上限是1MB。

  我们可以认为Zookeeper=文件系统+通知机制

  对于ZooKeeper的数据结构每个子目录项如 NameService 都被称作为 znode这个 znode 是被它所在的路径唯一标识如 Server1 这个 znode 的标识为 /NameService/Server1

  znode 可以有子节点目录并且每个 znode 可以存储数据注意 EPHEMERAL 类型的目录节点不能有子节点目录(因为它是临时节点)

  znode 是有版本的每个 znode 中存储的数据可以有多个版本也就是一个访问路径中可以存储多份数据

  znode 可以是临时节点一旦创建这个 znode 的客户端与服务器失去联系这个 znode 也将自动删除Zookeeper 的客户端和服务器通信采用长连接方式每个客户端和服务器通过心跳来保持连接这个连接状态称为 session如果 znode 是临时节点这个 session 失效znode 也就删除了

  znode 的目录名可以自动编号如 App1 已经存在再创建的话将会自动命名为 App2

  znode 可以被监控包括这个目录节点中存储的数据的修改子节点目录的变化等一旦变化可以通知设置监控的客户端这个是Zookeeper 的核心特性Zookeeper 的很多功能都是基于这个特性实现的。

  ZooKeeper的部署方式有单机模式和集群模式集群中的角色有Leader和Follower集群最少32N+1台根据选举算法应保证奇数。对于ZooKeeper集群过半存活即可使用。

1 ZooKeeper的选举机制

  假设有五台服务器组成的zookeeper集群它们的myid配置文件为从1到5同时它们都是最新启动的也就是没有历史数据在存放数据量这一点上都是一样的假设这些服务器依序启动

1服务器1启动此时只有它一台服务器启动了它发出去的报没有任何响应所以它的选举状态一直是LOOKING状态。

2服务器2启动它与最开始启动的服务器1进行通信互相交换自己的选举结果由于两者都没有历史数据所以id值较大的服务器2胜出但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3)所以服务器1、2还是继续保持LOOKING状态。

3服务器3启动根据前面的理论分析服务器3成为服务器1、2、3中的Leader而与上面不同的是此时有三台服务器选举了它所以它成为了这次选举的Leader。

4服务器4启动根据前面的分析理论上服务器4应该是服务器1、2、3、4中最大的但是由于前面已经有半数以上的服务器选举了服务器3所以它成为Follower。

5服务器5启动同4一样成为Follower。

注意如果按照5,4,3,2,1的顺序启动那么5将成为Leader因为在满足半数条件后ZooKeeper集群启动5的Id最大被选举为Leader。

2 客户端对ZooKeeper的ServerList的轮询机制

  客户端在初始化( new ZooKeeper(String connectString, int sessionTimeout, Watcher watcher) )的过程中将所有Server保存在一个List中然后随机打散形成一个环。之后从0号位开始一个一个使用。

两个注意点

  Server地址能够重复配置这样能够弥补客户端无法设置Server权重的缺陷但是也会加大风险。比如:192.168.1.1:2181,192.168.1.1:2181,192.168.1.2:2181).

  如果客户端在进行Server切换过程中耗时过长那么将会收到SESSION_EXPIRED. 这也是上面第1点中的加大风险之处。

3 客户端如何正确处理CONNECTIONLOSS(连接断开) 和 SESSIONEXPIRED(Session 过期)两类连接异常

  在ZooKeeper中服务器和客户端之间维持的是一个长连接在SESSION_TIMEOUT 时间内服务器会确定客户端是否正常连接(客户端会定时向服务器发送heart_beat),服务器重置下次SESSION_TIMEOUT时间。

  因此在正常情况下Session一直有效并且zk集群所有机器上都保存这个Session信息。在出现问题的情况下客户端与服务器之间连接断了客户端所连接的那台zk机器挂了或是其它原因的网络闪断这个时候客户端会主动在地址列表初始化的时候传入构造方法的那个参数connectString中选择新的地址进行连接。

  以上即为服务器与客户端之间维持长连接的过程在这个过程中用户可能会看到两类异常CONNECTIONLOSS(连接断开) 和SESSIONEXPIRED(Session 过期)。

  发生CONNECTIONLOSS后此时用户不需要关心我的会话是否可用应用所要做的就是等待客户端帮我们自动连接上新的zk机器一旦成功连接上新的zk机器后确认之前的操作是否执行成功了。

4 一个客户端修改了某个节点的数据其他客户端能够马上获取到这个最新数据吗

  ZooKeeper不能确保任何客户端能够获取即Read Request到一样的数据除非客户端自己要求方法是客户端在获取数据之前调用sync()方法。

  通常情况下这里所说的通常情况满足1. 对获取的数据是否是最新版本不敏感2. 一个客户端修改了数据其它客户端是否需要立即能够获取最新数据可以不关心这点。

  在其它情况下最清晰的场景是这样ZK客户端A对 /my_test 的内容从 v1->v2, 但是ZK客户端B对 /my_test 的内容获取依然得到的是 v1. 请注意这个是实际存在的现象当然延时很短。解决的方法是客户端B先调用 sync(), 再调用 getData()。

5 ZooKeeper对节点的watch监听是永久的吗为什么

  不是。

  官方声明一个Watch事件是一个一次性的触发器当被设置了Watch的数据发生了改变的时候则服务器将这个改变发送给设置了Watch的客户端以便通知它们。常见的监听有监听数据的变化和监听增减的变化。

  为什么不是永久的举个例子如果服务端变动频繁而监听的客户端很多情况下每次变动都要通知到所有的客户端这太消耗性能了。

  一般是客户端执行getData(“/节点A”,true)如果节点A发生了变更或删除客户端会得到它的watch事件但是在之后节点A又发生了变更而客户端又没有设置watch事件就不再给客户端发送。

  在实际应用中很多情况下我们的客户端不需要知道服务端的每一次变动我只要最新的数据即可。

  使用watch需要注意的几点

  ① Watches通知是一次性的必须重复注册.

  ② 发生CONNECTIONLOSS之后只要在session_timeout之内再次连接上即不发生SESSIONEXPIRED那么这个连接注册的watches依然在。

  ③ 节点数据的版本变化会触发NodeDataChanged注意这里特意说明了是版本变化。存在这样的情况只要成功执行了setData()方法无论内容是否和之前一致都会触发NodeDataChanged。

  ④ 对某个节点注册了watch但是节点被删除了那么注册在这个节点上的watches都会被移除。

  ⑤ 同一个zk客户端对某一个节点注册相同的watch只会收到一次通知。

  ⑥ Watcher对象只会保存在客户端不会传递到服务端。

6 能否为临时节点创建子节点

  ZooKeeper中不能为临时节点创建子节点如果需要创建子节点应该将要创建子节点的节点创建为永久性节点。

7 是否可以拒绝单个IP对ZooKeeper的访问如何实现

  ZK本身不提供这样的功能它仅仅提供了对单个IP的连接数的限制。你可以通过修改iptables来实现对单个ip的限制。

8 创建的临时节点什么时候会被删除是连接一断就删除吗延时是多少

  连接断了之后ZK不会马上移除临时数据只有当SESSIONEXPIRED之后才会把这个会话建立的临时数据移除。因此用户需要谨慎设置Session_TimeOut。

9 ZooKeeper集群中服务器之间是怎样通信的

  Leader服务器会和每一个Follower/Observer服务器都建立TCP连接同时为每个F/O都创建一个叫做LearnerHandler的实体。

  LearnerHandler主要负责Leader和F/O之间的网络通讯包括数据同步请求转发和Proposal提议的投票等。Leader服务器保存了所有F/O的LearnerHandler。

10 ZooKeeper节点类型

10.1 Znode有两种类型

  短暂ephemeral客户端和服务器端断开连接后创建的节点自己删除 。

  持久persistent客户端和服务器端断开连接后创建的节点不删除 。

10.2 Znode有四种形式的目录节点默认是persistent

1持久化目录节点PERSISTENT

  客户端与zookeeper断开连接后该节点依旧存在 。

2持久化顺序编号目录节点PERSISTENT_SEQUENTIAL

  客户端与zookeeper断开连接后该节点依旧存在只是Zookeeper给该节点名称进行顺序编号 。

3临时目录节点EPHEMERAL

  客户端与zookeeper断开连接后该节点被删除 。

4临时顺序编号目录节点EPHEMERAL_SEQUENTIAL

  客户端与zookeeper断开连接后该节点被删除只是Zookeeper给该节点名称进行顺序编号。

11 ZooKeeper使用到的各个端口的作用

  2888Follower与Leader交换信息的端口。

  3888万一集群中的Leader服务器挂了需要一个端口来重新进行选举选出一个新的Leader而这个端口就是用来执行选举时服务器相互通信的端口。

12 ZooKeeper使用的ZAB协议与Paxo算法的异同

  Paxos算法是分布式选举算法Zookeeper使用的 ZAB协议Zookeeper原子广播两者的异同如下

① 相同之处

  比如都有一个Leader用来协调N个Follower的运行Leader要等待超半数的Follower做出正确反馈之后才进行提案二者都有一个值来代表Leader的周期。

② 不同之处

  ZAB用来构建高可用的分布式数据主备系统ZookeeperPaxos是用来构建分布式一致性状态机系统。

13 ZooKeeper对事务性的支持

  ZooKeeper对于事务性的支持主要依赖于四个函数zoo_create_op_init zoo_delete_op_init zoo_set_op_init以及zoo_check_op_init。每一个函数都会在客户端初始化一个operation客户端程序有义务保留这些operations。当准备好一个事务中的所有操作后可以使用zoo_multi来提交所有的操作由zookeeper服务来保证这一系列操作的原子性。也就是说只要其中有一个操作失败了相当于此次提交的任何一个操作都没有对服务端的数据造成影响。Zoo_multi的返回值是第一个失败操作的状态信号。