zookeeper简单概述：受谷歌chubby论文影响，基于paxos算法实现的一款常用于分布式系统中的资源调度项目，由java语言实现，高可用，高效率。
框架角色： leader，follow，observer
一般搭建为主从结构，也是由于简化paxos算法，更加易于实现，作出的一些改变，即有一个leader主，若干follow从，其中会有observer角色，比follow更低级， 该角色具有功能仅仅用于主从数据同步等，不参与选举。
框架协议：ZAB协议，该协议即各角色，client（客户端）和server（服务端）之间的一种协调和数据同步机制，就是paxos算法实现的简化版本。（所以说zookeeper基于paxos算法实现）
其他重要功能 ：watch（观察者），react响应式开发，一种比较流行的开发方式，netty中用的淋漓尽致。
使用常见于：dubbo构建的分布式微服务系统，Hadoop生态中。（dubbo服务治理注册中心，activeMQ的集群中间调度，hdfs的主备协调中心）
类似项目工程：redis（redis的主从模式，redis有三种模式，主从，主从+哨兵，cluster集群模式，集群模式下无主，一般最少6个节点，三‘主’三备），redis也是基于paoxs算法
zookeeper有同步机制，也有恢复机制，即zookeeper各个客户端连接任意服务端时，leader和每个follow的数据是一样的，或者说具备最终一致性。也可以说它就是基于paoxs算法的消息最终一致性架构。具体它有一个log日志记录，或者说两阶段提交机制，类似分布式事务的TCC实现方式。简单解释：在zookeeper中leader具备读写改，一众follow节点只具备读，若有写请求会被follow转发去leader，leader操作完毕后将结果转给follow，follow返回结果给customer，在这期间由leader去执行’写改‘操作是因为，zookeeper维护了一个zxid事务id，在写改时，只能由leader进行增加，确保消息的最新和实时，保证各个follow节点与leader和他们自己之间的数据最终一致和选举机制正确可行性。再每次leader挂了后，新选举的leader会是一个新的代，每次数据写改也有自己的一个version号。zookeeper的数据更新也是先通知，各节点写日志记录，半数确认后再更新内存。
zookeeper可用来做分布式锁，是因为它的session可作为临时节点，session断开后，临时节点自动销毁，这个销毁时间可设置。zookeeper的节点是一种目录树结构，完全类似于数据结构中树结构，即可以在每个节点存数据，但是最大不超过1M，所以不要拿zookeeper当数据库来用，它的数据是和redis一样村于内存中的，磁盘中存的是一些log，用来做重启恢复等。
zookeeper常用命令 ： create （-s -e ） 节点名称 “节点数据” ，delete path ，ls / ，get ， set 等等。zookeeper的连接是不存在连接池的，就是因为它的session可作为临时节点存在，这是一个很秀的机制，所以我们可以基于这个来做分布式锁。
paxos算法：豆瓣网摩萨德小岛议员的故事，那篇文章很详尽。zookeeper源码可以不用看。