前言：
1、zookeeper是一个开源的分布式协调服务框架。
2、应用场景：分布式通知/协调、负载均衡、配置中心、分布式锁、分布式队列等。
3、使用ZAB协议。
4、Paxos算法
5、选举算法及流程
6、节点类型：持久节点、持久顺序节点、临时节点、临时顺序节点。
7、不是永久的，一次性的，需要借助第三方工具实现重复注册。
8、部署模式：单机模式、伪集群模式、集群模式。
9、集群角色：leader、foller、observer。
10、集群规则为2N+1台，N>0，即3台。
11、集群需要一半以上的机器可用，所以，3台挂掉1台还能工作，2台不能。
12、3.5版本开始支持动态扩容。
13、java客户端：zk自带的zkclient及Apache开源的Curator。
14、chubby是google的，完全实现paxos算法，不开源。zookeeper是chubby的开源实现，使用zab协议，paxos算法的变种。
15、常用命令：ls get set create delete等。
面试开始：
1、Zookeeper使用场景
zk 的使用场景如下：
分布式协调
分布式锁
元数据/配置信息管理
HA高可用性
分布式协调
这个其实是 zk 很经典的一个用法，简单来说，就好比，你 A 系统发送个请求到 mq，然后 B 系统消息消费之后处理了。那 A 系统如何知道 B 系统的处理结果？用 zk 就可以实现分布式系统之间的协调工作。A 系统发送请求之后可以在 zk 上对某个节点的值注册个监听器，一旦 B 系统处理完了就修改 zk 那个节点的值，A 立马就可以收到通知，完美解决。
分布式锁
举个栗子。对某一个数据连续发出两个修改操作，两台机器同时收到了请求，但是只能一台机器先执行完另外一个机器再执行。那么此时就可以使用 zk 分布式锁，一个机器接收到了请求之后先获取 zk 上的一把分布式锁，就是可以去创建一个 znode，接着执行操作；然后另外一个机器也尝试去创建那个 znode，结果发现自己创建不了，因为被别人创建了，那只能等着，等第一个机器执行完了自己再执行。
元数据/配置信息管理
zk 可以用作很多系统的配置信息的管理，比如 kafka、storm 等等很多分布式系统都会选用 zk 来做一些元数据、配置信息的管理，包括 dubbo 注册中心不也支持 zk 么？
HA高可用性
这个应该是很常见的，比如 hadoop、hdfs、yarn 等很多大数据系统，都选择基于 zk 来开发 HA 高可用机制，就是一个重要进程一般会做主备两个，主进程挂了立马通过 zk 感知到切换到备用进程。
引申Q:zookeeper满足了CAP的哪些特性
引申Q:讲讲CAP理念，ZAB协议。
引申Q:服务注册中心宕机了怎么办？zookeeper的事物，结点，服务提供方挂了如何告知消费方
简单来讲，zookeeper可以充当一个服务注册表（Service Registry），让多个服务提供者形成一个集群，让服务消费者通过服务注册表获取具体的服务访问地址（ip+端口）去访问具体的服务提供者。如下图所示：
具体来说，zookeeper就是个分布式文件系统，每当一个服务提供者部署后都要将自己的服务注册到zookeeper的某一路径上: /{service}/{version}/{ip:port}, 比如我们的HelloWorldService部署到两台机器，那么zookeeper上就会创建两条目录：分别为/HelloWorldService/1.0.0/100.19.20.01:16888 /HelloWorldService/1.0.0/100.19.20.02:16888。
zookeeper提供了“心跳检测”功能，它会定时向各个服务提供者发送一个请求（实际上建立的是一个 socket 长连接），如果长期没有响应，服务中心就认为该服务提供者已经“挂了”，并将其剔除，比如100.19.20.02这台机器如果宕机了，那么zookeeper上的路径就会只剩/HelloWorldService/1.0.0/100.19.20.01:16888。
服务消费者会去监听相应路径（/HelloWorldService/1.0.0），一旦路径上的数据有任务变化（增加或减少），zookeeper都会通知服务消费方服务提供者地址列表已经发生改变，从而进行更新。
更为重要的是zookeeper 与生俱来的容错容灾能力（比如leader选举），可以确保服务注册表的高可用性。
引申Q:zookeeper实现分布式锁
https://www.jianshu.com/p/e13ddf135a10
https://www.jianshu.com/p/9d3b1927e627
引申Q:5台服务器如何选出leader(选举算法)
结构图解释：左侧树状结构为zookeeper集群，右侧为程序服务器。所有的服务器在启动的时候，都会订阅zookeeper中master节点的删除事件，以便在主服务器挂掉的时候进行抢主操作；所有服务器同时会在servers节点下注册一个临时节点（保存自己的基本信息），以便于应用程序读取当前可用的服务器列表。 选主原理介绍：zookeeper的节点有两种类型，持久节点跟临时节点。临时节点有个特性，就是如果注册这个节点的机器失去连接(通常是宕机)，那么这个节点会被zookeeper删除。选主过程就是利用这个特性，在服务器启动的时候，去zookeeper特定的一个目录下注册一个临时节点(这个节点作为master，谁注册了这个节点谁就是master)，注册的时候，如果发现该节点已经存在，则说明已经有别的服务器注册了(也就是有别的服务器已经抢主成功)，那么当前服务器只能放弃抢主，作为从机存在。同时，抢主失败的当前服务器需要订阅该临时节点的删除事件，以便该节点删除时(也就是注册该节点的服务器宕机了或者网络断了之类的)进行再次抢主操作。从机具体需要去哪里注册服务器列表的临时节点，节点保存什么信息，根据具体的业务不同自行约定。选主的过程，其实就是简单的争抢在zookeeper注册临时节点的操作，谁注册了约定的临时节点，谁就是master。 其实简单来说就是利用了zookeeper的临时节点特性，服务器心跳宕机之后，节点会自动删除，新master会注册
三种实现：
1、javaAPI
2、zkclient实现，大部分逻辑代码都是一样的，可以参考javaApi原生代码实现
3、curator实现（有直接的选举功能）
引申Q:paxos（paxos是什么？什么是Lease机制？如何理解选主算法？）
2、consul 的可靠性你了解吗？
https://www.jianshu.com/p/5d3b8535e2ee
引申Q:那么consul是啥？
consul就是提供服务发现的工具,consul是分布式的、高可用、横向扩展的
3、consul 的机制你有没有具体深入过？有没有和其他的注册中心对比过？
ZooKeeper
历史悠久，数据存储格式类似文件系统，通过私有协议访问，集群式架构。优点是成熟稳定，缺点是系统复杂，资源占用高
etcd
etcd是通过HTTP协议访问的k/v存储系统，采用集群架构，容易部署和使用。但他更多功能是提供存储，要实现服务发现还得配合一些第三方的应用或者自己实现。 * “registrator”, 自动注册工具，将服务提供方的信息存储到etcd, consul这种kv存储系统 * ”confd“，轻量级的配置管理工具，他可以从etcd里取最新的服务信息生成配置文件，服务使用方就可以用它来实时更新配置文件
Consul
Consul 提供了高可用的kv存储，集群架构，这点和etcd zookeeper类似。 另外也提供了自动服务发现注册的套件，并且能否对服务进行健康检查。 结合consul-template可以实现服务提供方信息更新(比如增加了API服务器)时，自动生成配置文件给服务使用方自动更新配置。
补充知识点：
ZooKeeper，doozerd和etcd在他们的架构中都很相似。这三个服务器节点都需要一定数量的节点才能运行（通常是简单多数）。它们非常一致，并且可以通过应用程序中的客户端库来使用各种基元来构建复杂的分布式系统。
Consul还在单个数据中心内使用服务器节点。在每个数据中心，Consul服务器都需要一个法定人数来运行并提供强大的一致性。但是，Consul本身支持多个数据中心，以及一个功能更丰富的八卦系统，可以链接服务器节点和客户端。
在提供密钥/值存储时，所有这些系统都具有大致相同的语义：读取非常一致，并且在面对网络分区时牺牲了可用性以保持一致性。但是，当这些系统用于高级案例时，差异会变得更加明显。
这些系统提供的语义对构建服务发现系统很有吸引力，但重要的是要强调必须构建这些功能。ZooKeeper等。仅提供原始的K / V存储，并要求应用程序开发人员构建自己的系统以提供服务发现。相比之下，Consul为服务发现提供了一个固定的框架，并消除了猜测工作和开发工作。客户端只需注册服务，然后使用DNS或HTTP接口执行发现。其他系统需要家用轧制解决方案。
一个引人注目的服务发现框架必须包含健康检查和失败的可能性。如果节点A失败或服务崩溃，则知道节点A提供Foo服务是没有用的。朴素系统利用心跳，使用定期更新和TTL。这些方案需要与节点数量线性相关的工作，并将需求放在固定数量的服务器上。另外，故障检测窗口至少与TTL一样长。
ZooKeeper提供临时节点，这些节点是客户端断开连接时删除的K / V条目。这些比心跳系统更复杂，但仍然存在固有的可扩展性问题并增加了客户端的复杂性。所有客户端必须保持与ZooKeeper服务器的活动连接并执行保持活动。另外，这需要“厚客户端”，这些客户端难以编写并且经常导致调试挑战。
Consul使用一种非常不同的架构进行健康检查。Consul客户端不是仅具有服务器节点，而是在集群中的每个节点上运行。这些客户是八卦池的一部分它提供多种功能，包括分布式健康检查。八卦协议实现了一种有效的故障检测器，可以扩展到任何大小的集群，而无需将工作集中在任何选定的服务器组上。客户端还可以在本地运行更丰富的运行状况检查，而ZooKeeper临时节点是一种非常原始的活动检查。使用Consul，客户端可以检查Web服务器是否返回200个状态代码，内存利用率并不重要，磁盘空间足够等等.Consul客户端公开了一个简单的HTTP接口，并避免将系统的复杂性暴露给客户端与ZooKeeper一样。
Consul为服务发现，健康检查，K / V存储和多个数据中心提供一流的支持。除了简单的K / V存储之外，所有其他系统都需要额外的工具和库来构建。通过使用客户端节点，Consul提供了一个只需要瘦客户端的简单API。此外，可以通过使用配置文件和DNS接口完全避免API，以获得完全没有开发的服务发现解决方案。
参考链接：https://www.consul.io/intro/vs/zookeeper.html