分布式协调服务——Zookeeper

Zookeeper 是一个分布式服务框架，是 Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。分布式协调技术主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源，防止造成"脏数据"的后果。

 

数据结构：

　　Zookeeper 数据结构与树类似，由节点组成。数据存储也同样基于节点 Znode，不同于树的节点，Znode 引用方法是路径引用。这样的层级结构让每个节点都拥有唯一的路径，就像命名空间一样将不同的信息清晰的隔离开来。

　　Znode：

　　　　data：数据信息。

　　　　ACL：记录 Znode 的访问权限。

　　　　stat：Znode 的元数据。如事务Id、版本号、时间戳、大小等。

　　　　child：子节点引用。

　　Zookeeper 是为读多写少的场景设计的，Znode 无法用来存储大规模的业务数据，只能用于存储少量状态和配置信息，每个节点的数据最大不能超过 1 MB。

 

　　Znode类型：

　　　　持久节点（PERSISTENT）：默认的节点类型。创建节点的客户端与 Zookeeper 断开连接后，该节点依旧存在。

　　　　持久顺序节点（PERSISTENT_SEQUENTIAL）：所谓顺序节点，就是在创建节点时，Zookeeper 根据创建的时间顺序给该节点名称进行编号。

　　　　临时节点（EPHEMERAL）：创建节点的客户端与 Zookeeper 断开连接后，临时节点会被删除。

　　　　临时顺序节点（EPHEMERAL_SEQUENTIAL）：在创建节点时，Zookeeper 根据创建的时间顺序给该节点名称进行编号；当创建节点的客户端与 Zookeeper 断开连接后，临时节点会被删除。

 

Watch 事件通知：

　　Zookeeper 使用了观察者设计模式。当 Znode 发生改变时，如调用了create()、delete()、setData()，会触发 Znode 上相应的注册事件，此时请求 Watch 的客户端会接收到异步通知。

　　交互过程：

　　　　1、客户端调用 getData 方法，watch 参数是 true。服务端接到请求，返回节点数据，并且在对应的哈希表里插入被 Watch 的 Znode 路径，以及 Watcher 列表。

　　　　2、当被 Watch 的 Znode 已删除，服务端会查找哈希表，找到该 Znode 对应的所有 Watcher，异步通知客户端，并且删除哈希表中对应的 Key-Value。

Zookeeper一致性问题：

　　Zookeeper 维护了一个集群，集群采用一主多从结构。更新数据时先更新到主节点服务器，然后再同步到从节点服务器。读取数据可以从任意节点读取。

　　为了保证主从节点的数据一致性，Zookeeper 采用了 ZAB 算法（Zookeeper Atomic Broadcast），有效解决了 Zookeeper 集群崩溃恢复，以及主从同步数据的问题。

 

　　ZAB协议的三种状态：

• Looking ：选举状态。
• Following ：Follower 节点（从节点）所处的状态。
• Leading ：Leader 节点（主节点）所处状态。

 

　　ZAB的故障恢复过程：

　　　　选举阶段：

　　　　　　此时，集群中的节点处于 looking 状态，分别向其他节点发起投票，投票信息中包含自己的服务器ID和最新事务ID（ZXID）。收到投票信息的节点将自身ZXID与其他节点的 ZXID 比较，如果其他节点的 ZXID 较大，则重新发起投票，投票给 ZXID 最新的节点。当集群中的某个节点得到半数以上的投票后该节点将成为准 Leader，状态更新为 leading，其他节点状态更新为 following。

　　　　发现阶段：

　　　　　　用于在从节点中发现最新 ZXID 和事务日志。为了防止在选举阶段产生多个准 Leader，此阶段准 Leader 节点将接收所有 Follower 发来各节点的最新 epoch 值。准 Leader 从中选出最大的 epoch，基于此值加 1，生成新的 epoch 分发给各个 Follower。各个 Follower 收到全新的 epoch 后，返回 ACK 给 Leader，带上各自最大的 ZXID 和历史事务日志。Leader 选出最大的 ZXID，并更新自身历史日志。

　　　　同步阶段：

　　　　　　Leader 将发现阶段收集的最新历史事务日志同步给 Follower 节点，当半数以上 Follower 节点同步完成时，准 Leader 节点成为正式的 Leader 节点。至此故障恢复完成。

 

　　ZAB的数据同步：

　　　　1、用户将写请求发送给 Follower 服务器；

　　　　2、Follower 服务器将请求转发给 Leader 服务器；

　　　　3、Leader 采用二阶段提交方式，先发送 Propose 广播给 Follower；

　　　　4、Follower 接到 Propose 消息，写入日志成功后，返回 ACK 消息给 Leader；

　　　　5、Leader 接到半数以上ACK消息，返回成功给客户端，并且广播 Commit 请求给 Follower。

 

　　ZAB 协议既不是强一致性，也不是弱一致性，而是处于两者之间的单调一致性（顺序一致性）。它依靠事务 ID 和版本号，保证了数据的更新和读取是有序的。