从集中式部署业务架构到 分布式部署，Master-Worker架构 改造过程中，必然涉及数据一致性问题
2pc，3pc都没很好解决这个问题，ZooKeeper 站出来解决这个问题。
-
应用的协调服务。
-
分布式应用的协调服务。
-
协调分布式应用的服务的服务(中间件)
使用Zoo keeper ，一个普通服务 做很少改造机就能升级为分布式服务，协调应用直接数据一致性问题。
ZooKeeper is coordination service for distributed applications.
ZooKeeper 是伴随Hadoop产生的， 而Hadoop生态系统中，很多项目都是以动物来命名，如Pig，Hive等， 似乎像一个动物园，这样就得到动物园管家的名称”ZooKeeper”
微服务相关的项目都纷纷抛弃ZK转投etcd，可见其确实有可取之处，也可以看出一个项目的易用的重要性有时候甚至高于稳定性和功能
可扩展性不足，ZK集群不支持在线动态添加机器或替换机器
-
不适合用于大容量存储。
对于大容量存储 ，我们完全可以考虑使用数据库或者分布式文件系统等
Zookeeper 是一个基于 Google Chubby 论文实现的一款解决分布式数据一致性问题的开源实现，方便了依赖 Zookeeper 的应用实现
-
数据发布 / 订阅
-
负载均衡
-
服务注册与发现
-
分布式协调
-
事件通知
-
集群管理
-
Leader 选举
-
分布式锁和队列
-
ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持崩溃恢复的原子广播协议.专为ZK设计的
2pc和3pc的分析中可以看出，出现不一致的情况都是因为执行rollback操作导致的，同步阻塞本来就性能差，而且还要等待所有的参与者回复才能做出决策，这导致性能更差。
Zab在汲取了这些经验后，其在设计上不允许执行rollback操作，协调者(zab中是leader)发出的请求，参与者(zab中是Follower)要么同意，要么丢弃，且协调者在收到一半的回复后，就能做出决策，发出提交申请，同样在得到一半的回复后，能够完成事务
zk很好的解决了2pc和3pc的各种问题，且也不会有单点问题
| 产品 | 一致性 | 角色 | ||
|---|---|---|---|---|
| ZooKeeper | 过半 | leader,followers,Observer（只读节点） | ||
http://www.jasongj.com/zookeeper/fastleaderelection/