《从 PAXOS 到 ZOOKEEPER：分布式一致性原理与实践》读书笔记

1 Zookeeper 概论

Zookeeper 是一个分布式数据管理与协调框架，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。分布式应用程序可以基于它实现诸如数据发布/订阅，负载均衡，命名服务，分布式协调/通知，集群管理，Master 选举，分布式锁和分布式队列等功能。

Zookeeper 可以保证如下分布式一致性特性：

• 顺序一致性：从同一个客户端发起的事务请求，最终将会严格按照其发起顺序被应用到 Zookeeper 中
• 原子性：所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的。
• 单一视图：客户端连接任何一个 Zookeeper 服务器，其看到的服务端数据模型都是一致的
• 可靠性：事务所引起的服务端状态变更将会一直被保留下来
• 实时性：保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态

2 ZAB 协议

ZAB 协议是为分布式协调服务 zookeeper 专门设计的一种支持崩溃恢复的原子广播协议，基于该协议，Zookeeper 实现了一种主备模式的系统架构来保持集群中各副本之间的数据的一致性。

2.1 协议内容

ZAB 协议包括两种基本的模式，分别是崩溃恢复和消息广播。当整个服务框架在启动过程中，或者是当 Leader 服务器出现网络中断，崩溃退出与重启等异常情况时，ZAB 协议就会进入恢复模式并选举产生新的 Leader 服务器。当选举产生新的 Leader 服务器，同时集群中已经有过半的机器与该 Leader 服务器完成状态同步后，ZAB 协议就会退出恢复模式。这时候整个服务框架就进入消息广播模式，当其他服务器加入集群后就会自觉进行数据恢复模式，找到 Leader 所在的服务器，并与其进行数据同步。

3 Zookeeper 使用

可参考此 Zookeeper 学习

4 Zookeeper 应用

4.1 数据发布/订阅

发布者将数据发布到 Zookeeper 的一个或者一系列节点上，客户端向服务端注册自己需要关注的节点，一旦该节点的数据发生变更，那么服务端就会向相应的客户端发送 Watcher 事件通知，客户端接收到这个消息通知后，需要主动到服务端获取最新的数据。

4.2 命名服务

在 Zookeeper 中，每一个数据节点都能够维护一份子节点的顺序序列，当客户端对其创建一个顺序子节点的时候 Zookeeper 会自动以后缀的形式在其子节点上添加一个序号，客户端拿到这个返回值后，再拼接上 type 类型，这就可以作为一个全局唯一的 ID 了。

4.3 分布式协调/通知

不同的客户端都对 Zookeeper 上同一个数据节点进行 Watcher 注册，监听数据节点的变化（包括数据节点本身及其子节点），如果数据节点发生变化，那么所有订阅的客户端都能够收到相应的 Watcher 通知并做出相应的处理

4.4 集群管理

集群管理主要有两点：机器的加入和退出、master 选举

• 利用 Zookeeper 的 Watcher 监听和临时节点特性，可以实时检测机器的变动情况
• 客户端集群每天会定时往 Zookeeper 节点 A 下创建一个临时节点，在这个过程中，只有一个客户端能够成功创建这个节点（强一致性），那么这个客户端所在的机器就成了 master，同时其他没有在 Zookeeper 上成功创建节点的客户端，都会在节点 A 上注册一个子节点变更的 Watcher，用于监控当前的 master 机器是否存活，一旦发现当前的 master 挂了，那么其余的客户端将会重新进行 master 选举

4.5 分布式队列

所有客户端都会到 A 节点下创建一个临时顺序节点，创建一个临时顺序节点，创建玩节点后，通过调用 getChildren() 接口来获取 A 节点下的所有子节点，即获取队列中的所有元素，确定自己的节点序号在所有子节点中的顺序，如果自己不是序号最小的子节点，那么就需要进入等待，同时比向自己序号小的最有一个节点注册 watcher 监听，接收到 watcher 通知后，重复以上步骤。