ZooKeeper概念与应用
Zookeeper是开源的分布式协调服务，提供了分布式数据一致性的解决方案。
Zookeeper 可用作配置中心和分布式锁服务，在 Dubbo、Kafka、Spark等分布式集群上得到广泛应用。
ZNode
Zookeeper的数据模型为树状结构，树的节点被称作ZNode。
Zookeeper使用路径来唯一标识ZNode，类似于Unix文件系统中的绝对路径。路径必须以/开头，由Unicode字符串组成，如/myapp/master/0。
每一个ZNode维护着三部分数据:
- stat: 节点状态信息，包括版本、更改时间、访问控制等
- data: 节点的内容数据，Zookeeper限制每个节点数据不超过1M。Zookeeper设计用来进行协调调度，请勿在其中存放大量数据。
- children: 该ZNode的子节点。
每个节点都有独立的访问控制列表(Access Control List, ACL), 来控制用户对本节点的访问权限。
每个ZNode都维护着三个版本号:
- dataVersion: 节点数据版本号
- cversion: 子节点版本号
- aclVersion: 节点访问控制列表版本号
所有的写操作都会使相应的版本号增加。写操作必须指定要更新的ZNode的版本号，版本号不一致会导致写入失败。
Zxid
所有对Zookeeper状态的改变都会产生一个Zxid(ZooKeeper Transaction Id），Zxid全局有序。
Zxid为标识事件发生的先后顺序: 即事件A发生早于事件B，那么事件A的Zxid定小于事件B的Zxid。
每个ZNode维护两个Zxid:
- cZxid: Znode创建
- mZxid: Znode最近修改
Zxid是一个64位的数字, 高32位表示Zookeeper集群leader, 低32位表示逻辑顺序。每次leader改变后, 新产生的Zxid高32位都会改变。
节点类型
Zookeeper中的节点分为两种:
- 临时节点: 临时节点依赖于创建节点的会话(Session), 一旦Session结束临时节点会被自动删除。临时节点不允许拥有子节点
- 永久节点: 永久节点生存期不依赖于客户端会话，只有客户端执行删除操作时才会删除。
Zookeeper 可以创建顺序子节点，即创建子节点时在路径结尾添加一个自增的32位 id, 该id在该节点的父节点下是唯一的。
Watch
Zookeeper 所有的读操作getData(), getChildren()和 exists()都可以设置 Watch 触发器。
Watch 触发器是一次性的，当触发器通知了一次状态变化后消失，不会通知状态的再次变化。
Zookeeper 与客户端之间通过 Tcp Socket 进行通信， Zookeeper 会主动将时间通知客户端。
Zookeeper 保证客户端只有首先收到了Watch通知后，才会感知到它所设置监视的znode发生了变化。
Zookeeper 支持三种类型的watch:
- exists: 被监视的Znode 创建、删除、数据改变时被触发
- getData: 被监视的Znode 删除、数据改变时被触发
- getChildren: 被监视的Znode 删除、创建子节点、删除子节点时被触发
Zookeeper 应用
ZooKeeper 是具有较高一致性的分布式协调服务，它提供以下保证:
- 原子性: 所有操作具有原子性
- 分布式一致性： 从任意节点中读取到的数据都是一致的
- 顺序一致性: 从一个客户端来的更新请求会被顺序执行; 写操作是全局有序的;
- 持久性: 写操作一旦成功，直到被覆盖为止持续有效
Zookeeper 使用数据副本和崩溃恢复机制保证数据安全和集群高可用性。
Zookeeper 使用基于 Paxos 算法的 ZAB协议(Zookeeper Atomic Broadcast)进行写操作，保证集群数据的一致性。
配置中心
我们可以将系统中通用配置信息写入 ZNode 中，客户端启动时从 Zookeeper 获取配置数据并监视配置节点的变化，当配置发生改变 Zookeeper 会通知所有的客户端获取最新数据，从而实现在线更新配置。
适合使用Zookeeper维护的配置通常:
- 数据量较小
- 在运行时动态发生变化
- 各客户端读取到数据需要相同
- 具有顺序一致性，客户端只要读取到新版本的数据，此后就不能读取到旧版本数据
当服务启动时，服务提供者可以在Zookeeper的相应路径下创建临时节点，并在节点中写入服务配置信息。服务关闭(崩溃)时，临时节点自动删除。
客户端启动时从 ZooKeeper 读取服务提供者信息从而实现自动的服务发布/移除功能。
分布式锁
Zookeeper 的临时节点可以维护客户端持有锁的状态，加锁失败的客户端可以使用 Watch 机制监视锁的释放情况，实现阻塞等待加锁。
Zookeeper 的顺序节点可以实现一个简单的队列，可以利用此特性实现公平锁。客户端在锁节点下创建顺序子节点，持有最小子节点的客户端成功加锁，加锁失败的客户端 Watch 前一个顺序子节点，从而实现先到先得的公平锁机制。
命名服务
ZooKeeper 的顺序节点可以生成全局唯一ID, 我们可以利用该ID为服务命名。相对于UUID, 该名称较短且可以保证绝不重复。
Master选举
与分布式公平锁应用类似，ZooKeeper 可以维护集群 Master。
集群中所有可以成为 Master 的进程都在 Zookeeper 中的指定路径下创建顺序子节点，持有最小子节点的进程成为Master。
集群中所有进程都 Watch 指定路径下节点的情况，一旦发生变化则重新读取最小子节点的持有者作为Master。
脑裂问题
传统集群实现方案是运行一个备用Master节点，备用Master节点定期向主Master节点发送ping请求，若能及时收到主Master的ack响应则认为正常。
若Ack响应超时，备用Master则会取代原主Master成为新的集群主Master节点。
若响应超时因为主Master故障导致，备用Master成为新的主节点完全正常。
若超时因为主备 Master 节点间 ping-ack 网络故障导致，那么主Master工作正常，而备用Master却误认为主Master崩溃而进行取代，那么集群中可能出现多个Master共存的故障(即脑裂故障)。
若使用 Zookeeper 维护 Master 信息，无论是因为主Master故障还是通信问题导致最小子节点被删除，备用Master持有的节点都会成为最小子节点。
此时，所有客户端都会受到通知并得知 Master 变更，保证集群中只有一个 Master。
当崩溃的Master恢复后，它将成为新的备用Master加入集群。
ZooKeeper 无法避免通信故障导致误判 Master 状态，但是可以保证在任何情况下集群中只有一个 Master 节点。
