zookeeper基本概念

1. 什么是ZooKeeper

ZooKeeper是一种高可用的一致性协调框架，可以理解为一个轻量级的分布式内存文件系统，它内部使用ZAB协议作为一致性算法。它的内部提供了多层级的节点名空间（称为znode），客户端可以对znode进行监听，常见的应用场景主要为：分布式协调、分布式锁、元数据/配置信息管理、HA高可用等。

2. 文件系统的四种znode

在第一节中已经介绍ZooKeeper内部文件实现是基于znode节点，znode节点一般是由客户端为了自己的业务需求而在ZooKeeper内创建的，为了实现不同的业务场景，客户端创建的znode分为了四种不同的类型：

• 持久化目录节点： 客户端与zookeeper断开连接后，节点数据依然存在
• 持久化顺序编号目录节点： 客户端断开连接后，节点不仅存在，而且在创建之时zookeeper会给该类型的znode节点加上一个顺序的编号。
• 临时目录节点： 客户端与zookeeper断开连接后，节点数据就会被删除
• 临时顺序编号目录节点： 客户端断开连接后节点数据删除，但是创建之时会有对应的编号来排序

3. 应用场景实例分析

分布式协调： 这一般是用的最为广泛的场景，就是A系统发送一条消息到消息中间件中，然后B系统会去消费处理这条消息，但是这条消息的处理时间是不一定的，所以A系统发完消息之后不可能一直等待返回结果，这个时候A可以在zookeeper中创建一个节点znode，然后注册一个监听器，然后B在处理完毕后，修改该节点上的数据触发A注册的监听器通知A消息处理完毕。

分布式锁：这里只是介绍zookeeper分布式锁实现的基本思想，具体实现其实会更加详细。假设两个请求同时要对某一条数据进行修改，那么修改前要求它们必须先到zookeeper建立对应znode节点，先到的请求在建立了znode后可以进行后续处理，但是晚到的请求发现zookeeper上已经有了对应节点，则会对该节点进行监听，只要该节点被释放删除了，说明上个请求已经处理完毕了，那么等待的请求就会去重新创建节点然后执行操作。通过这种方式，就可以实现分布式锁。

元数据/配置信息管理：我们现在所知道的很多分布式中间件都会需要管理配置信息/元数据，例如hbase、kafka、storm等等，这些服务都会选择把集群中共享的一些配置信息以及集群信息等数据给托管到zookeeper中进行管理。

HA高可用：这个最常见的就是hadoop、hdfs、yarn等的高可用就是借助zookeeper来实现的，实现的原理就是主备两个进程，主节点会在zookeeper上创建一个临时的znode，备用节点就在这个临时节点上创建监听器，只要主节点挂掉了就会导致临时节点被删除，从而备用节点就能感知到马上进行主备切换，并建立对应的znode临时节点说明自己切换到为了主节点。

4. zookeeper服务器节点类型

zookeeper服务器节点类型分为三种：Leader、Follower、Observer，下面分别介绍三种节点类型。

• Leader：一个zookeeper集群同一个时间只能有一个实际工作的Leader，Leader主要负责维护和各个Follower以及Observer之间的心跳，以及统一处理所有写请求。 zookeeper中任意的节点都可以接收客户端的写请求，但是非Leader节点接收到客户端写请求后，都会转发到Leader由Leader先完成写请求后然后广播给所有其它节点来完成该写请求，最终只有半数以上的节点（不包括Observer节点）返回写请求成功后，该请求才会被提交并返还告知客户端写入成功。
• Follower：Follower可直接处理并返回客户端的读请求，但是对于写请求必须转发到Leader，这里需要注意由于Leader对于写请求commit成功的条件只要有一半以上的节点响应写入成功就认为写入成功，然后后续再对没来得及写入的节点数据进行同步，但是zookeeper中Follower又是可以处理读请求的，读取的就是请求节点的本地数据，所以可能会读取到过期的数据！！
• Observer：Observer节点和Follower十分类似，区别就是Follower不参与投票（写请求commit投票以及leader选举时的投票），之所以加入这个是因为如果只有Leader和Follower，那么在对zookeeper集群进行扩展的时候，由于每个写请求需要半数以上的节点确认成功才能commit，那么如果zookeeper的Follower过多，则会影响写请求的效率，这种情况下就可以加入Observer节点类型，这种节点因为不参与投票，所以扩展时可以加Observer进行扩展，这样可以提高读取性能，但是不会影响写入性能。