zookeeper

[wittyResry]

• zookeeper作为一个分布式协调系统在hadhoop中被广泛的应用，其中HBase默认带有zookeeper。zookeeper的主要功能有配置维护、分布式锁、选举、分布式队列等等，并且zookeeper本身可以是一个集群，提供了高可用性。同时zookeeper提供了一些简单易用的api，方便开发。
• The name space provided by ZooKeeper is much like that of a standard file system. A name is a sequence of path elements separated by a slash (/). Every node in ZooKeeper's name space is identified by a path.
• 其中的每个节点称为znode，每个znode节点既可以包含数据又可以包含子节点，由于zookeeper被定位为协调程序因此znode中存储的数据通常不会太大，一般会存储一些状态信息，位置信息等等，zookeeper官方建议znode中的数据不要超过1M。
• znode有两种类型的节点：临时节点，永久节点，其中这两种节点又分为有序和无序。重点讲一下临时节点，因为zk中很多基础的功能都是基于临时节点实现的，client在和zookeeper连接的时候两者之间会建立通讯，连接状态存储在zookeeper服务端维护的session中。随着session的超时服务端会将client建立的所有临时节点移除，而永久节点即使客户端退出节点也不会消失。同时临时节点不能有子节点但是可以挂载数据。znode节点结合watcher机制可以实现非常丰富和灵活的功能。

zookeeper集群结构:

高可用性

• zookeeper中的高可用性是通过数据冗余来实现的，也就是一份数据存在多个节点中，zookeeper要求同一份数据需要在超过一半的节点上存在，只有这样才能使得宕机数量的容忍度更高。zk建议集群中配置奇数个节点，这是因为在flower同步数据和进行leader选举的时候都要求有超过一半完成或同意才算ok。举例来说，假如有3个节点，至少需要有2个节点正常，就是容忍度为1（允许宕掉的节点数），有4个节点，至少需要有三个节点正常，容忍度同样为1，多出来一个机器但是容忍度相同在任何时候看来都得不偿失，因此zk建议集群中部署奇数个节点，但这不是强制。另外再看一下为什么写操作的时候要求至少有超过一半节点commit成功整体才成功，假如有2t+1个zk节点，也就是必须有t+1个节点commit成功才ok，因为只有这种情况下才能达成至少有一个节点存有前后两次的更新操作（两次更新至少涉及到2t+2个节点，至少有一个节点有两次更新的记录）。zookeeper使用zab算法实现数据的原子广播，并且每次write操作会写日志然后更新缓存，每个zk节点维护一个全局变量zxid，随着znode的每一次改变而递增，当leader挂掉的时候，剩余的flower选择zxid最大的节点作为新的leader，在新leader提供服务前还需要一次数据恢复，新leader只是拥有最多的数据（zxid最大），但不一定拥有最新的数据，因此leader和flower的数据需要同步到最新的状态，通过合并的过程完成整个数据的恢复。

配置管理

• 如果是单机或者几台机器，当应用配置项变更的时候，可能通过手动的方式去修改一下，但是假如一个集群中有成百上千个应用节点，如何才能保证快速无差错的完成配置项的变更。zookeeper的出现可以轻松地解决这个问题

Watch机制

• zookeeper允许客户端对znode节点或者节点中的数据设置监听器，当znode改变的时候服务器触发监听，客户端完成一个回调完成自己的业务逻辑。zookeeper中的watch是一次性的，也就是当监听触发后监听器便失效了，需要再次应用watcher。exists，getData，getChildren接口都可以指定是否应用watcher，可以使用默认的watcher或者自定义watcher。触发watcher的接口可以为create、delete、setData、setACL。 REF: http://zookeeper.apache.org/doc/current/zookeeperOver.html

Leader选举

• zookeeper本身提供leader选举机制，大概的思路是所有节点创建临时有序的znode然后监听所有节点的变化情况，获取最小序号和自己创建的序号作比较，如果自己为最小则当选为leader。当leader主动删除节点或者宕机后，临时节点消失，该变化会被其他存活的节点获取到从而触发第二次的leader选举，依次类推。实际上zookeeper提到的很多recipes curator（对zookeeper api很好的封装）都提供了很好的实现（除了两阶段提交），同时基于底层的zookeeper api开发应用需要考虑的东西很多，curator对这些都提供了封装，所以如果要编写zookeeper应用推荐使用curator。

• leader应用的场景很广泛，curator提供了两种不同的选举实现，一种是轮询做leader，另外一种是永久获取leader权直到节点退出，两种选举实现可以在不同的集群应用中发挥作用。