什么是Zookeeper
ZooKeeper 是 Apache 软件基金会的一个软件项目，它为大型分布式计算提供开源的分布式配置服务、同步服务和命名注册等服务。
ZooKeeper的三种运行模式
单机模式、伪集群模式和集群模式。
- 单机模式：Zookeeper只运行在一台服务器上，一般适用于开发测试环境，一方面我们没有那么多机器资源，另外就是平时的开发调试并不需要极好的稳定性。
- 集群模式：Zookeeper运行在一个物理集群上，适合生产环境。一般 3 台以上可以组成一个可用的 ZooKeeper 集群。组成 ZooKeeper 集群的每台机器都会在内存中维护当前的服务器状态，并且每台机器之间都会互相保持通信。
- 伪集群模式：一台物理机上运行多个Zookeeper实例。这是一种特殊的集群模式，即集群的所有服务器都部署在一台机器上。ZooKeeper 允许我们在一台机器上通过启动不同的端口来启动多个 ZooKeeper 服务实例，从而以集群的特性来对外服务。
Zookeeper主要功能
- 配置管理：在多个应用程序(或服务器)中，将相同的配置信息放在配置中心，即zookeeper，需要的时候直接拉取，在需要对配置信息进行修改的时候，可以直接修改，这样可以大大节约维护的成本。
- 分布式锁：在多个用户访问同一台主机上的应用程序数据时，可以使用加锁解决并发操作的问题；但是如果有多台主机相同的应用程序要访问同一数据时，如果变量A存在三个服务器内存中（这个变量A主要体现是在一个类中的一个成员变量，是一个有状态的对象），如果不加任何控制的话，变量A同时都会在分配一块内存，三个请求发过来同时对这个变量操作，显然结果是不对的！即使不是同时发过来，三个请求分别操作三个不同内存区域的数据，变量A之间不存在共享，也不具有可见性，处理的结果也是不对的！这时候就需要zookeeper的分布式锁的功能。
- 集群管理：zookeeper作为注册中心，管理服务提供方的ip地址端口号url信息，并在服务消费方请求需要时发送给服务消费方。
Zookeeper的特点
- 集群：Zookeeper是一个领导者（Leader），多个跟随者（Follower）组成的集群。
- 高可用性：集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。
- 全局数据一致：每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据都是一致的。
- 更新请求顺序进行：来自同一个Client的更新请求按其发送顺序依次执行。
数据更新原子性：一次数据更新要么成功，要么失败。 - 实时性：在一定时间范围内，Client能读到最新数据。
- 从设计模式角度来看，Zookeeper是一个基于观察者设计模式的框架，它负责管理跟存储大家都关心的数据，然后接受观察者的注册，数据反生变化Zookeeper会通知在Zookeeper上注册的观察者做出反应。
- Zookeeper是一个分布式协调系统，满足CP性，跟SpringCloud中的Eureka满足AP不一样。
什么是CAP
计算机机专家Eric Brewer于2000年在ACM分布式计算原理专题讨论会（PODC）中提出的分布式系统设计要考虑三个核心要素：一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），而这三个特性不可能同时满足。三个特性的说明如下：
-
一致性（
Consistency）: 同一时刻同一请求的不同实例返回的结果相同，这要求数据具有强一致性(Strong Consistency) -
可用性（
Availability） : 所有读写请求在一定时间内得到正确的响应 -
分区容错性（
Partition tolerance）: 在网络异常情况下，系统仍能正常运作。
CAP认为分布式环境下网络的故障是常态，比如我们多机房部署下机房间就可能发生光缆被挖断、专线故障等网络分区情况（导致部分节点无法通信，原本一个大集群变成多个独立的小集群），也可能出现网络波动、丢包、节点宕机等，所以分布式系统设计要考虑的是在满足P的前提下选择C还是A。
例如：要开发一个分布式缓存服务，只提供简单的读取与写入功能，服务支持多个节点做数据冗余及负载，请求由网关随机分发到其中一个节点，我们必须确保其中一个或几个节点故障时另一些节点仍然可以提供服务，在网络分区形成独立小集群时也可以提供服务，这就必须满足分区容错性（P），我们假设部署了两个服务节点，那么：
如果要保证一致性（C），即所有节点可查询到的数据随时随刻都是一致的（同步中的数据不可查询），就要求一个节点写入数据后必须再将数据写入到另一个节点后才能返回成功，这样当我们读取之前写入的数据时才能确保一致，但上文说明过网络异常在所难免，如果两个服务节点无法相互通讯时为保证一致性在数据写入发现无法同步到另一节点时就会返回错误进而牺牲了可用性（A）。
如果要保证可用性（A），即只要不是服务宕机所有请求都可得到正确的响应，那么在网络异常节点不能通讯的情况下要让数据没有同步到另一节点的请求也返回成功，这就必须牺牲一致性（C）导致在一段时间内（网络异常期间）两个服务节点所查询到的数据可能不同。
所以从中可以简单地发现一致性（C）与可用性（A）是不可能同时满足的。同FLP Impossibility 一样CAP理论也为我们做分布式服务架构指明了方向：分布式系统中我们只能选择CP（满足一致性牺牲可用性）或AP（满足可用性牺牲一致性）。
当我们选择CP，即满足一致性而牺牲可用性时意味着在网络异常出现多个节点孤岛时为了保证各个节点的数据一致系统会停止服务，反之选择AP，即满足可用性牺牲一致性时网络异常时系统仍可工作，但会出现各节点数据不致的情况。