ZooKeeper是一个分布式数据一致性的解决方案，可以基于它实现数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。
ZooKeeper特性
顺序一致性
从同一个客户端发起的事务请求，最终会严格按照发起的顺序被应用到ZooKeeper中去。
原子性
所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的。要么所有机器都应用了某一个事务，要么都没有。
单一视图
无论客户端连接的是哪个ZooKeeper服务器，其看到的服务端数据模型都是一致的。
可靠性
一旦服务端成功的应用了一个事务，并完成对客户端的响应，那么服务端的状态变更会被一直保留下来。个人认为，这应该是持久性。
实时性
这里是指，ZooKeeper仅仅能保证在一定时间内，客户端最终一定能从服务端读取到最新的数据状态。
ZooKeeper基本概念
集群角色
ZooKeeper中有三个角色——Leader、Follower和Observer。所有机器中选定一台作为Leader，其他机器包括Follower和Observer。Follower和Observer都能提供读服务。而Observer不参与选举Leader的过程，也不参与写操作的“过半成功”策略，因此Observer可以在不影响写性能的情况下提升集群的读性能。
会话（Session）
在ZooKeeper中，一个客户端连接是指客户端和服务器之间的一个TCP长连接。当服务器压力太大、网络故障或是客户端主动断开连接等各种原因使得
数据节点（ZNode）
节点分两类，机器节点和数据节点。这里说的数据节点为ZNode。ZooKeeper将所有数据存储在内存中，数据模型是一棵树（ZNode Tree），由“/”进行分割。每个ZNode都会保存自己的数据内容，还有数据信息。ZNode也分为两种——持久节点和临时节点。临时节点和会话Session相关联，持久节点，除非将其移除才会失效。另外，ZooKeeper的节点有一个特殊属性：SEQUENTIAL。有了这个标记，ZooKeeper会自动在其节点后面追加上一个整形数字，这个数字是由父节点维护的自增数字。
版本
对于ZNode，ZooKeeper都会维护一个Stat的数据结构，Stat中记录了这个ZNode的三个数据版本，分别是version（当前ZNode的版本）、cversion（当前ZNode子节点的版本）和aversion（当前ZNode的ACL版本）。
时间监听器 （Watcher）
ZooKeeper允许用户用指定节点上注册一些Watcher，触发的时候会将事件通知到感兴趣的客户端上去。
ACL
ZooKeeper采用ACL策略来进行权限控制。
在深入了解ZooKeeper之前，很多人认为ZooKeeper就是Paxos算法的一个实现。但事实上ZooKeeper并没有完全采用Paxos算法，而是使用了一种称为ZooKeeper Atomic Broadcast（ZooKeeper原子消息广播协议）的协议作为数据一致性的核心算法。
ZAB协议的核心定义了对于那些改变ZooKeeper服务器数据状态的事务请求的处理方式，即：
所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被成为Leader服务器，而余下的其他服务器则成为Follower服务器。Leader服务器负责将一个客户端事务请求转换成一个事务Proposal（提议），并将该Proposal分发给集群中所有的Follower服务器。之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确的反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求其将前一个Proposal进行提交。
更多精彩内容，欢迎关注微信公众号：Java小笔记（ijavanote）
