1、为什么使用Zookeeper
Zookeeper是一个文件系统的数据结构
（1） Zookeeper是Googel的Chubby的一个开源实现，是Hadoop的分布式协调服务，它包好了一个简单的原语，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等。
（2） Zookeeper本身也允许单机模式，但是一台服务器很难表达出zookeeper的强大功能，所以真是生产环境下zookeeper一班都是3台以上的奇数量的存在，证实了zookeeper本身是一个分布式集群的存在。
（3） ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
（4）ZooKeeper代码版本中，提供了分布式独享锁、选举、队列的接口，代码在zookeeper-3.4.3\src\recipes。其中分布锁和队列有Java和C两个版本，选举只有Java版本
a. 大部分的分布式应用程序都需要一个主控、协调器或者控制器来物理分布的子进程（如资源，内存分配等）
b. 目前大部分应用开发私有的协调程序，缺乏一个通用性
c. 协调程序的反复编写浪费，难以形成通用、伸缩性好的协调器
d. ZooKeeper：提供通用的分布式锁服务，用以协调分布式应用
从目前来看有两个点好看
第一个就是：分布式事务
第二个就是：文件系统的数据结构（存储一些公共数据：如配置信息，不必要每个部署环境都配置一份）
第三个就是：做Service发现服务（ServiceDiscovery），在微服务来临的今天。Duubo 或者 Spring cloud，同一业务模块我一次可能就是部署十台服务器，那么我来一个请求，我如果自己去做请求，那么我该去请求哪一台？这样专业的事情就交给Zookeeper或者eureka这种发现服务去处理。文章最后我在网上看到有个朋友写的挺好的，加上了。
2、什么是分布式
小饭店原来只有一个厨师，切菜洗菜备料炒菜全干。后来客人多了，厨房一个厨师忙不过来，又请了个厨师，两个厨师都能炒一样的菜，这两个厨师的关系是集群。为了让厨师专心炒菜，把菜做到极致，又请了个配菜师负责切菜，备菜，备料，厨师和配菜师的关系是分布式，一个配菜师也忙不过来了，又请了个配菜师，两个配菜师关系是集群。
3、分布式与集群有什么区别
集群是个物理形态，分布式是个工作方式
集群是：同一件业务服务，部署到多个物理端，这个是集群。
分布式：同一业务拆分成多个业务，比如：登录系统：
原来的主线是：登录—>安全检测—>日志—>个人信息—>个人权限信息
拆分为：登录接口、日志记录模块、安全检测模块、个人信息模块、个人权限模块
不必需要使用同步处理，异步处理即可，能够节省大量的运算时间。
后话：在拆分到不能拆分后，我们还是会有新的集群，比如讲，用户量上去后，我们会把登录接口再做集群，分散到多个不同物理机器，分布式、集群一般都是伴随着的。
4、分布式的CAP
一致性：Consistency
可用性：Availability
分区容错性：Partitiontolerance
一致性：数据修改后必须多地同步修改了
可用性：24小时全时段的服务不中断
分区容错性：就是有备份系统，如 一个master,多个backup
CA(放弃P) 将所有的数据放在一个库，满足一致性和可用性。代表：关系型数据库
CP(放弃A) 放弃可用性，来保持一致性。代表：zookeeper
AP(放弃C) 放弃一致性，适合不需要一致性的场合。代表：eureka
5、Zookeeper能解决发现服务问题
最近碰到有人问，使用dubbo时为什么要用zookeeper作为注册中心，zookeeper是如何起作用的？
我把我的理解说了一下。
先给他探讨性地说明了一些背景问题：
首先，为什么用dubbo？不就是因为dubbo能够帮我们解决分布式系统远程接口相互调用的问题吗？那在一个分布式系统中，大量的接口怎么实现相互调用呢，毕竟调用者和被调用者可能在2台不同的机器上。
当然，我们有很多办法来实现。最简单的，在配置文件中将所有要调用的接口的地址配置好，要用时通过web的方式调用即可。
但是，但是，，，很多分布式系统之间的调用不是一对多，或者多对一的，而是一个多对多的网状。即A可能调用B、C、D接口，B也可能调用A、C、D接口，以此类推。如果接口的数量是个位级的（个位级也就不用DUBBO了）还好办，如果是2位的甚至3位级的，那以后维护这些接口将会是一个灾难！为何呢？如果某一接口换了机器IP或者新增了一个将被调用很多的接口，那就是系统性的程序变更了，对一个生产系统来说风险挺大！
好，现在说正题：
如果将一个系统比作一个项目团队，则该系统内的相互接口调用，就类似于团队之间的沟通协作。比如，需求人员员要找开发人员确认需求，开发人员要找测试人员测试需求，测试人员要找需求人员验收需求等等。团队各种不同类型的人员可能来自不同部门。
如果是小团队，大家集中从在一个办公室，有什么事面对面直接沟通即可，这就类似于我们同一工程内接口的调用，直接new对象或通过spring配置的即可。
如果是一个大型团队，大家可能坐在不同办公室甚至不同城市，沟通就只能通过打电话或发邮件了（这里的电话系统或邮件系统就是DUBBO了）。想想看，如果没有一个统一的通讯录，每个人就要自己搞一个通讯本记录自己要沟通的人员的电话或邮件。这个通讯本可能千差万别，有人用纸，有人用笔记本，有人用电脑，有人用手机等等。。。（这里的通讯本记录方式就类似于我们对接口的记录方式，纸和笔记本就类似于直接记在程序中的，电脑和手机类似于记在配置文件中）。万一哪天某一个关键人物的联系方式变了，那大家有得忙了，用电脑和手机的还好，改改就好了。用了纸和和笔记本的，就只能换一张纸甚至换一个笔记本了。而且，让项目经理头疼的是，有些人可能没改或者改错，遇到关键问题时因找不到人发生不可预料事件（类比于我们生产事故）！
那像这种大型团队的沟通问题怎么解决呢？人家说这还不超级简单嘛，搞个统一的通讯录，专人管理，上面记录所有人的联系方式，如果某人联系方式有变动，通知专人修改通讯录即可，然后大家要联系某人时，通过人名查找通讯录不就行了嘛！
对！就是这么简单！zookeeper就是这个通讯录和管通讯录的人！
如果回到我们的系统中，接口名就是人名（不过在dubbo中这个人名不能重复），接口实现就是这个人，接口IP地址就是联系电话或邮件，电话系统或邮件系统就是dubbo！
这么一说，问我的人立即就明白了，zookeeper的作用是不是就很好理解了呵呵。
第五点引用：https://www.2cto.com/kf/201708/668587.html