1.zookeeper是什么
zookeeper是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、master选举、分布式锁和分布式队列等功能。
2.分布式常见的问题
问题
如下图：假设一个集群下有三个服务：orderService1、orderService2、orderService3。
比如为了解决多个服务准确并且只能执行一次task任务，这里的task可以当做一个共享资源，如何解决多个服务在并发争取资源的时候，有且只能有一个能成功执行，其他的不能执行
思考1：每个服务都有一个配置文件，配置文件里的信息动态变更了，如何保证各节点数据的一致性？
思考2：如何保证一个任务只在orderService1上执行呢？
思考3：如果orderService1服务挂掉了，其他的服务怎么知道它挂掉了，并且去接替它的任务？
思考4：存在一个共享资源，如何保证节点访问共享资源间的互斥性或安全性？（类似多个线程访问同一资源）
解决方案
为了解决以上这些问题，zookeeper就诞生了！
首先，zookeeper是一个类似文件目录的存储结构。它的节点特性里存在有序节点，可以先让这三个服务orderService1、orderService2、orderService3注册到zookeeper上，相当于在zookeeper上创建了三个有序节点。拿到序号最小的那个节点（也就是最先创建的那个节点），认为它具有优先权，那么orderService1就能够优先处理任务Task，orderService2和orderService3不满足条件，拒绝处理该任务。
3.Zookeeper 的前世今生
从上面的案例可以看出，分布式系统的很多难题，都是由于缺少协调机制造成的。在分布式协调这块做得比较好的，有Google 的 Chubby以及 Apache 的 Zookeeper。
Google Chubby 是一个分布式锁服务，通过 GoogleChubby 来解决分布式协作、Master 选举等与分布式锁服务相关的问题。
Zookeeper 也是类似，因为当时在雅虎内部的很多系统都需要依赖一个系统来进行分布式协调，但是谷歌的Chubby是不开源的，所以后来雅虎基于 Chubby 的思想开发了zookeeper，并捐赠给了 Apache。在上面这个架构下 zookeeper 以后，可以用来解决 task 执行问题，各个服务先去 zookeeper 上去注册节点，然后获得权限以后再来访问 task
4.zookeeper 的设计猜想
zookeeper 主要是解决分布式环境下的服务协调问题而产生的，如果我们要去实现一个 zookeeper 这样的中间件，我们需要做什么？
怎么防止防止单点故障
如果要防止 zookeeper 这个中间件的单点故障，那就势必要做集群。而且这个集群如果要满足高性能要求的话，还得是一个高性能高可用的集群。高性能意味着这个集群能够分担客户端的请求流量，高可用意味着集群中的某一个节点宕机以后，不影响整个集群的数据和继续提供服务的可能性。
结论：所以这个中间件需要考虑到集群，而且这个集群还需要分摊客户端的请求流量。数据如何同步
接着上面那个结论再来思考，如果要满足这样的一个高性能集群，我们最直观的想法应该是，每个节点都能接收到请求，并且每个节点的数据都必须要保持一致。要实现各个节点的数据一致性，就势必要一个 leader 节点负责协调和数据同步操作。这个我想大家都知道，如果在这样一个集群中没有 leader 节点，每个节点都可以接收所有请求，那么这个集群的数据同步的复杂度是非常大的。
结论：所以这个集群中会涉及到数据同步以及会存在 leader 节点。怎么解决leader挂了的问题
继续思考，如何在这些节点中选举出 leader 节点，以及 leader 挂了以后，如何恢复呢？
结论：所以zookeeper 用了基于 paxos 理论所衍生出来的 ZAB 协议。如何保存数据同步一致性
leader 节点如何和其他节点保证数据一致性，并且要求是强一致的。在分布式系统中，每一个机器节点虽然都能够明确知道自己进行的事务操作过程是成功和失败，但是却无法直接获取其他分布式节点的操作结果。所以当一个事务操作涉及到跨节点的时候，就需要用到分布式事务，分布式事务的数据一致性协议有 2PC 协议和3PC 协议。
基于这些猜想，我们基本上知道 zookeeper 为什么要用到
zab理论来做选举、为什么要做集群、为什么要用到分布式事务来实现数据一致性了。
