分布式所产生的一些问题
假设一个集群下有三个服务：orderService1、orderService2、orderService3。
思考1：每个服务都有一个配置文件，配置文件里的信息动态变更了，如何保证各节点数据的一致性？
思考2：如何保证一个任务只在orderService1上执行呢？
思考3：如果orderService1服务挂掉了，其他的服务怎么知道它挂掉了，并且去接替它的任务？
思考4：存在一个共享资源，如何保证节点访问共享资源间的互斥性或安全性？（类似多个线程访问同一资源）
为了解决以上这些问题，zookeeper就诞生了！
zookeeper解决 思考2
首先，zookeeper是一个类似文件目录的存储结构。它的节点特性里存在有序节点，可以先让这三个服务orderService1、orderService2、orderService3注册到zookeeper上，相当于在zookeeper上创建了三个有序节点。拿到序号最小的那个节点（也就是最先创建的那个节点），认为它具有优先权，那么orderService1就能够优先处理任务Task，orderService2和orderService3不满足条件，拒绝处理该任务。
zookeeper的设计猜想
zookeeper 主要是解决分布式环境下的服务协调问题而产生的，如果我们要去实现一个 zookeeper 这样的中间件，我们需要做什么？
1》防止单点故障
如果要防止 zookeeper 这个中间件的单点故障，那就势必要做集群。而且这个集群如果要满足高性能要求的话，还得是一个高性能高可用的集群。高性能意味着这个集群能够分担客户端的请求流量，高可用意味着集群中的某一个节点宕机以后，不影响整个集群的数据和继续提供服务的可能性。
结论：所以这个中间件需要考虑到集群，而且这个集群还需要分摊客户端的请求流量。
2》数据同步和存在leader节点
接着上面那个结论再来思考，如果要满足这样的一个高性能集群，我们最直观的想法应该是，每个节点都能接收到请求，并且每个节点的数据都必须要保持一致。要实现各个节点的数据一致性，就势必要一个 leader 节点负责协调和数据同步操作。这个我想大家都知道，如果在这样一个集群中没有 leader 节点，每个节点都可以接收所有请求，那么这个集群的数据同步的复杂度是非常大的。
结论：所以这个集群中会涉及到数据同步以及会存在 leader 节点。
3》ZAB 协议
继续思考，如何在这些节点中选举出 leader 节点，以及 leader 挂了以后，如何恢复呢？
结论：所以 zookeeper 用了基于 paxos 理论所衍生出来的 ZAB 协议。
leader 节点如何和其他节点保证数据一致性，并且要求是强一致的。在分布式系统中，每一个机器节点虽然都能够明确知道自己进行的事务操作过程是成功和失败，但是却无法直接获取其他分布式节点的操作结果。所以当一个事务操作涉及到跨节点的时候，就需要用到分布式事务，分布式事务的数据一致性协议有 2PC 协议和3PC 协议。
基于这些猜想，我们基本上知道 zookeeper 为什么要用到 zab 理论来做选举、为什么要做集群、为什么要用到分布式事务来实现数据一致性了。