zookeeper 核心概念与架构总结
一. ZooKeeper是什么
ZooKeeper 是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能，ZooKeeper可以保证如下分布式一致性特性。
- 顺序一致性
从同一个客户端发起的事务请求，最终将会严格地按照其发起顺序被应用到ZooKeeper中去。
- 原子性
所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群所有机器都成功应用了某一个事务，要么都没有应用，一定不会出现集群中部分机器应用了该事务，而另外一部分没有应用的情况。
- 单一视图
无论客户端连接的是哪个ZooKeeper服务器，其看到的服务端数据模型都是一致的。
- 可靠性
一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会被一直保留下来，除非有另一个事务又对其进行了变更。
- 实时性
通常人们看到实时性的第一反应是，一旦一个事务被成功应用，那么客户端能够立即从服务端上读取到这个事务变更后的最新数据状态。这里需要注意的是，ZooKeeper仅仅保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。
二. ZooKeeper基本概念
2.1 集群角色
Zookeeper引入了 Leader、Follower 和 Observer 三种角色。ZooKeeper 集群中的所有机器通过一个Leader选举过程来选定一台被称为“Leader”的机器，Leader服务器为客户端提供读和写服务。除 Leader外，其他机器包括 Follower 和 Observer。Follower和 Observer都能够提供读服务。
2.2 会话（Session）
Session 是指客户端会话，一个客户端连接是指客户端和服务器之间的一个TCP长连接。
2.3 数据节点（Znode）
在ZooKeeper中，“节点”分为两类，第一类同样是指构成集群的机器，我们称之为机器节点；第二类则是指数据模型中的数据单元，我们称之为数据节点——ZNode。ZooKeeper将所有数据存储在内存中，数据模型是一棵树（ZNode Tree），由斜杠（/）进行分割的路径，就是一个Znode，例如/foo/path1。每个ZNode上都会保存自己的数据内容，同时还会保存一系列属性信息。
在ZooKeeper中，ZNode可以分为持久节点和临时节点两类。
- 持久节点，指一旦这个ZNode被创建了，除非主动进行ZNode的移除操作，否则这个ZNode将一直保存在ZooKeeper 上。
- 临时节点，它的生命周期和客户端会话绑定，一旦客户端会话失效，那么这个客户端创建的所有临时节点都会被移除。
ZooKeeper 还允许用户为每个节点添加一个特殊的属性：SEQUENTIAL。一旦节点被标记上这个属性，那么在这个节点被创建的时候，ZooKeeper 会自动在其节点名后面追加上一个整型数字，这个整型数字是一个由父节点维护的自增数字。
2.4 版本
对应于每个 ZNode，ZooKeeper都会为其维护一个叫作Stat的数据结构，Stat中记录了这个ZNode的三个数据版本，分别是
- version（当前ZNode的版本）
- cversion（当前ZNode子节点的版本）
- aversion（当前ZNode的ACL版本）。
2.5 Watcher
Watcher（事件监听器），ZooKeeper 允许用户在指定节点上注册一些 Watcher，并且在一些特定事件触发的时候，ZooKeeper 服务端会将事件通知到感兴趣的客户端上去，该机制是ZooKeeper实现分布式协调服务的重要特性。
2.6 ACL
ZooKeeper采用ACL（Access Control Lists）策略来进行权限控制，类似于UNIX文件系统的权限控制。ZooKeeper定义了如下5种权限。
- CREATE：创建子节点的权限。
- READ：获取节点数据和子节点列表的权限。
- WRITE：更新节点数据的权限。
- WRITE：更新节点数据的权限。
- DELETE：删除子节点的权限。
- ADMIN：设置节点ACL的权限。
三. ZAB协议
3.1 ZAB协议概述
Zookeeper使用了一种称为 ZooKeeper Atomic Broadcast（ZAB，ZooKeeper原子消息广播协议）的协议作为其数据一致性的核心算法。ZAB 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。
ZAB协议的主要目标是确保ZooKeeper集群中所有服务器之间数据的一致性。它通过支持主从复制和原子广播来实现。ZAB将ZooKeeper集群划分为两种角色：Leader（领导者）和Follower（追随者）。
3.2 ZAB协议基本原理
- 选举Leader：当ZooKeeper集群启动时，所有服务器都是Follower状态。在这种状态下，它们互相通信，主要使用基于服务器之间的通信延迟和服务器的编号的算法，选举出一个Leader。
- 原子广播：一旦Leader选举完成，它就会接收来自客户端的写请求。Leader接收到这些写请求后，会将它们转化为一个事务（Transaction）并赋予一个全局唯一的递增编号。然后，Leader将该事务广播给所有的Follower。
- Follower的数据同步：当Follower收到Leader广播的事务时，它会将该事务应用到自己的数据状态中。这确保了所有服务器的数据状态保持一致。
- 处理Follower崩溃：当一个Follower崩溃或者新加入集群时，它会向Leader发送一个请求，请求将当前的数据状态传送给它。Leader会将整个数据状态发送给该Follower，或者在该Follower的数据状态较老时，只发送未曾传送过的部分数据。
- Leader崩溃：如果Leader崩溃，ZAB会启动新一轮的Leader选举过程，选出一个新的Leader。
总结：
ZAB协议通过Leader选举和原子广播机制确保了ZooKeeper集群中所有服务器之间数据的一致性。Leader负责接收客户端的写请求，将其转化为事务，并通过广播使所有Follower的数据状态保持一致。当服务器崩溃或新服务器加入时，ZAB能够处理状态同步，保持数据的完整性和一致性。这使得ZooKeeper可以用于构建各种分布式应用，如分布式锁、配置管理等等。