Zookeeper简介
zookeeper是一个分布式服务框架，是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。前面的解释有点官方，简单来说zookeeper=文件系统+监听通知机制。
注：客户端与服务端之间的连接是基于 TCP 长连接，底层默认是通过 java 的 NIO 方式，也可以配置 netty 实现方式。client 端连接 server 端默认的 2181 端口，也就是 session 会话。从第一次连接建立开始，客户端开始会话的生命周期，客户端向服务端的ping包请求，每个会话都可以设置一个超时时间。
zookeeper 数据结构
zookkeeper 提供的名称空间非常类似于标准文件系统，key-value 的形式存储。名称 key 由斜线 / 分割的一系列路径元素，zookeeper 名称空间中的每个节点都是由一个路径标识。
相关 CAP 理论
CAP 理论指出对于一个分布式计算系统来说，不可能同时满足以下三点：
- 一致性：在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性，等同于所有节点访问同一份最新的数据副本。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。
-
可用性：每次请求都能获取到正确的响应，但是不保证获取的数据为最新数据。
-
分区容错性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。
一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
在这三个基本需求中，最多只能同时满足其中的两项，P 是必须的，因此只能在 CP 和 AP 中选择，zookeeper 保证的是 CP，对比 spring cloud 系统中的注册中心 eruka 实现的是 AP。
BASE 理论
BASE 是 Basically Available(基本可用)、Soft-state(软状态) 和 Eventually Consistent(最终一致性) 三个短语的缩写。
-
基本可用：在分布式系统出现故障，允许损失部分可用性（服务降级、页面降级）。
-
软状态：允许分布式系统出现中间状态。而且中间状态不影响系统的可用性。这里的中间状态是指不同的 data replication（数据备份节点）之间的数据更新可以出现延时的最终一致性。
- 最终一致性：data replications 经过一段时间达到一致性。
BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。
四种类型的znode
-
PERSISTENT-持久化目录节点
客户端与zookeeper断开连接后，该节点依旧存在
-
PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
-
EPHEMERAL-临时目录节点
客户端与zookeeper断开连接后，该节点被删除
-
EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号
Zookeeper 节点特性
1、同一级节点 key 名称是唯一的
2、创建节点时，必须要带上全路径
3、session 关闭，临时节点清除
4、自动创建顺序节点
5、watch 机制，监听节点变化
事件监听机制类似于观察者模式，watch 流程是客户端向服务端某个节点路径上注册一个 watcher，同时客户端也会存储特定的 watcher，当节点数据或子节点发生变化时，服务端通知客户端，客户端进行回调处理。特别注意：监听事件被单次触发后，事件就失效了。
提示：参考常用命令章节 get 命令监听 watch 使用，后面章节将详细介绍 watch 实现原理。
6、delete 命令只能一层一层删除
提示：新版本可以通过 deleteall 命令递归删除。
有了上述众多节点特性，使得 zookeeper 能开发不出不同的经典应用场景，比如：
- 数据发布/订阅
- 负载均衡
- 分布式协调/通知
- 集群管理
- master 管理
- 分布式锁
利用 zookeeper 的同级节点的唯一性特性，多个用户在某个菜单下同时创建临时子节点，创建成功的获得分布式锁，其他没获得锁的用户在该菜单下注册一个子节点变更的watcher监听事件，以便重新争取获得锁。
- 分布式队列
Zookeeper 数据同步流程
在 Zookeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性。
ZAB 协议分为两部分：
- 消息广播
- 崩溃恢复
消息广播
Zookeeper 使用单一的主进程 Leader 来接收和处理客户端所有事务请求（即使是Follower节点接收到请求也会转发给Leader，再由Leader发送事务请求给所有Follower节点），并采用 ZAB 协议的原子广播协议，将事务请求以 Proposal 提议广播到所有 Follower 节点，当集群中有过半的Follower 服务器进行正确的 ACK 反馈，那么Leader就会再次向所有的 Follower 服务器发送commit 消息，将此次提案进行提交。这个过程可以简称为 2pc 事务提交，整个流程可以参考下图，注意 Observer 节点只负责同步 Leader 数据，不参与 2PC 数据同步过程。
崩溃恢复
在正常情况消息广播情况下能运行良好，但是一旦 Leader 服务器出现崩溃，或者由于网络原理导致 Leader 服务器失去了与过半 Follower 的通信，那么就会进入崩溃恢复模式，需要选举出一个新的 Leader 服务器。在这个过程中可能会出现两种数据不一致性的隐患，需要 ZAB 协议的特性进行避免。
- Leader 服务器将消息 commit 发出后，立即崩溃
- Leader 服务器刚提出 proposal 后，立即崩溃
ZAB 协议的恢复模式使用了以下策略：
- 选举 zxid 最大的节点作为新的 leader
- 新 leader 将事务日志中尚未提交的消息进行处理