走进大数据丨 ZooKeeper

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现。它提供了简单原始的功能，分布式应用可以基于它实现更高级的服务，比如分布式同步，配置管理，集群管理，命名管理，队列管理。它被设计为易于编程，使用文 件系统目录树作为数据模型。服务端跑在java上，提供java和C的客户端API众所周知，协调服务非常容易出错，但是却很难恢复正常，例如，协调服务很容易处于 静态以至于出现死锁。我们设计ZooKeeper的目的是为了减轻分布式应用程序所承担的协 调任务ZooKeeper是集群的管理者，监视着集群中各节点的状态，根据节点提交的反馈进行下一步合理的操作。最终，将简单易用的接口和功能稳定，性能高效的系统提供给用户。

Zookeeper的特点

最终一致性：为客户端展示同一视图，这是zookeeper最重要的功能。 

可靠性：如果消息被到一台服务器接受，那么它将被所有的服务器接受。 

实时性：Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。 

等待无关（wait-free）：慢的或者失效的client不干预快速的client的请求。 

原子性：更新只能成功或者失败，没有中间状态。 

顺序性：所有Server，同一消息发布顺序一致。

ZooKeeper中的时间

致使ZooKeeper节点状态改变的每一个操作都将使节点接收到一个Zxid格式的时间戳，并且这个时间戳全局有序。也就是说，每个对节点的改变都将产生一个唯一的Zxid。如果Zxid1的值小于Zxid2的值，那么Zxid1所对应的事件发生在Zxid2所对应的事件之前。实际上，ZooKeeper的每个节点维护值三个Zxid值，分别为：cZxid、mZxid、pZxid。

1.cZxid：是节点的创建时间所对应的Zxid格式时间戳。

2.mZxid：是节点的修改时间所对应的Zxid格式时间戳。

3.pZxid：是与该节点的子节点（或该节点）的最近一次创建/删除的时间戳对应。

ZooKeeper监听工作原理

ZooKeeper的Watcher机制主要包括客户端线程、客户端WatcherManager、Zookeeper服务器三部分。客户端在向ZooKeeper服务器注册的同时，会将 Watcher 对象存储在客户端的WatcherManager当中。当ZooKeeper服务器触发Watcher事件后，会向客户端发送通知，客户端线程从WatcherManager中取出对应的Watcher对象来执行回调逻辑。

ZooKeeper基本架构

1.每个Server在内存中存储了一份数据； 

2.Zookeeper启动时，将从实例中选举一个leader（Paxos协议）； 

3.Leader负责处理数据更新等操作（Zab协议）； 

4.一个更新操作成功，并且当大多数Server在内存中成功修改数据。

架构角色

领导者（Leader）：负责投票的发起和决议，更新系统状态。

学习者（Learner）：

1.跟随者（Follower）：Follower用于接收客户请求并向客户端返回结果，在选主过程中参与投票。

2.观察者（ObServer）：ObServer可以接收客户端的连接，将写请求转发给leader节点，但是ObServer不参与投票过程，只同步leader的状态，ObServer的目的是为了扩展系统，提高读取速度。

客户端（Client）：请求发起方。