前言

一般人对于zookeeper的绝大多数印象就是他是用来做协调服务的，不管说是Hadoop，HBase，Storm等等这些计算平台，都或多或少用到了这个zookeeper"动物管理员"。使用的方法都很简单，首先搭建一个zookeeper集群，然后在配置文件中指定一下ip:host，然后就可以用了，但是很少有人会问，zookeeper是如何进行工作的，他是如何为其他节点进行服务的呢。

2PC和3PC

说起zookeeper就不得说2个著名的协议，2pc，3pc，在之前其实我也只是通过2pc，就是two phase commit，2阶段提交协议嘛，很有名的一致性协议，3pc自然指的就是三阶段提交协议，他在2pc协议的基础上改进了其中的同步阻塞，协调者的单点问题等等，但是实现的复杂度确实也提升了许多。具体的知识点博友们可以上网去搜索一些资料。

Paxos与Zookeeper

上面说的2个协议只是一个铺垫，在一致性协议中最最有名的应该算是Paxos协议了吧，他是一种基于消息传递且具有高度容错性的一致性算法。Google Chubby作为一个分布式的锁服务，就是以Paxos算法为基础而实现的。那么Zookeeper与Paxos难道就没有任何关系了吗，事实是这样的，Zookeeper是Google Chubby的开源实现，Zookeeper的设计目标就是要解决分布式环境中一致性的问题的，是典型的分布式一致性问题的解决方案。

Zookeeper简单的数据模型

Zookeeper作为一个协调服务，其中很多时间要做的是就是存储一些元数据，你可以理解为是许多的状态数据，这些数据是保存在一个共享的，树型结构的结构中，每个节点叫做znode，每个节点有他自己的命名空间，类似于Unix中的文件系统的结构，不过人家没有文件和目录的概念，这些数据模型都是统一存放在内存中，方便应用的快速读取，以此实现高服务器的吞吐。

Zookeeper的主从结构

Zookeeper采用的也是master/slave的结构，master节点在Zookeeper中叫做leader，其他的slave叫做follower,所有的由客户端发送过来的事务更新请求都是由leader节点处理，然后再提供异步的方式同步到各个foller节点中。

ZAB协议

上文中已经提及过Zookeeper并没有采用Paxos协议，而是采用自己的ZAB协议，全称为Zookeeper Atomic Broadcast原子广播协议，zab协议能够保证一个全局的变更序列被顺序应用，其中会用到CAS的一些操作，也就是是乐观锁的一些手段，通过比较version版本号，判断在事务操作的过程中，是否有其他的操作已经发生。