共计 5098 个字符，预计需要花费 13 分钟才能阅读完成。
1、Zookeeper 的角色
- 领导者（leader），负责进行投票的发动和决定，更新零碎状态。
- 学习者（learner），包含跟随者（follower）和观察者（bserver），follower 用于承受客户端申请并想客户端返回后果，在选主过程中参加投票
- Observer 能够承受客户端连贯，将写申请转发给 leader，但 observer 不加入投票过程，只同步 leader 的状态，observer 的目标是为了扩大零碎，进步读取速度
- 客户端（client），申请发起方
Zookeeper 的外围是原子播送，这个机制保障了各个 Server 之间的同步。实现这个机制的协定叫做 Zab 协定。Zab 协定有两种模式，它们别离是恢复模式（选主）和播送模式（同步）。当服务启动或者在领导者解体后，Zab 就进入了恢复模式，当领导者被选举进去，且大多数 Server 实现了和 leader 的状态同步当前，恢复模式就完结了。状态同步保障了 leader 和 Server 具备雷同的零碎状态。
为了保障事务的程序一致性，zookeeper 采纳了递增的事务 id 号(zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了 zxid。实现中 zxid 是一个 64 位的数字，它高 32 位是 epoch 用来标识 leader 关系是否扭转，每次一个 leader 被选出来，它都会有一个新的 epoch，标识以后属于那个 leader 的统治期间。低 32 位用于递增计数。
• 每个 Server 在工作过程中有三种状态：
LOOKING：以后 Server 不晓得 leader 是谁，正在搜查
LEADING：以后 Server 即为选举进去的 leader
FOLLOWING：leader 曾经选举进去，以后 Server 与之同步
其余可考查：[https://www.cnblogs.com/lpshou/archive/2013/06/14/3136738.html](https://www.cnblogs.com/lpshou/archive/2013/06/14/3136738.html)
2、Zookeeper 的读写机制
*Zookeeper 是一个由多个 server 组成的集群
* 一个 leader，多个 follower
* 每个 server 保留一份数据正本
* 全局数据统一
* 分布式读写
* 更新申请转发，由 leader 施行
3、Zookeeper 的保障
* 更新申请程序进行，来自同一个 client 的更新申请按其发送程序顺次执行。* 数据更新原子性，一次数据更新要么胜利，要么失败。* 全局惟一数据视图，client 无论连贯到哪个 server，数据视图都是统一的。* 实时性，在肯定事件范畴内，client 能读到最新数据。4、Zookeeper 节点数据操作流程
注：1. 在 Client 向 Follwer 收回一个写的申请
2.Follwer 把申请发送给 Leader
3.Leader 接管到当前开始发动投票并告诉 Follwer 进行投票
4.Follwer 把投票后果发送给 Leader
5.Leader 将后果汇总后如果须要写入，则开始写入同时把写入操作告诉给 Leader，而后 commit;
6.Follwer 把申请后果返回给 Client
• Follower 次要有四个性能：
• 1. 向 Leader 发送申请（PING 音讯、REQUEST 音讯、ACK 音讯、REVALIDATE 音讯）；
• 2 . 接管 Leader 音讯并进行解决；
• 3 . 接管 Client 的申请，如果为写申请，发送给 Leader 进行投票；
• 4 . 返回 Client 后果。
• Follower 的音讯循环解决如下几种来自 Leader 的音讯：
• 1 .PING 音讯：心跳音讯；
• 2 .PROPOSAL 音讯：Leader 发动的提案，要求 Follower 投票；
• 3 .COMMIT 音讯：服务器端最新一次提案的信息；
• 4 .UPTODATE 音讯：表明同步实现；
• 5 .REVALIDATE 音讯：依据 Leader 的 REVALIDATE 后果，敞开待 revalidate 的 session 还是容许其承受音讯；
• 6 .SYNC 音讯：返回 SYNC 后果到客户端，这个音讯最后由客户端发动，用来强制失去最新的更新。
5、Zookeeper leader 选举
• 半数通过
– 3 台机器 挂一台 2>3/2
– 4 台机器 挂 2 台 2！>4/2
• A 提案说，我要选本人，B 你批准吗？C 你批准吗？B 说，我批准选 A；C 说，我批准选 A。(留神，这里超过半数了，其实在事实世界选举曾经胜利了。
然而计算机世界是很严格，另外要了解算法，要持续模仿上来。)
• 接着 B 提案说，我要选本人，A 你批准吗；A 说，我曾经超半数批准入选，你的提案有效；C 说，A 曾经超半数批准入选，B 提案有效。
• 接着 C 提案说，我要选本人，A 你批准吗；A 说，我曾经超半数批准入选，你的提案有效；B 说，A 曾经超半数批准入选，C 的提案有效。
• 选举曾经产生了 Leader，前面的都是 follower，只能遵从 Leader 的命令。而且这里还有个小细节，就是其实谁先启动谁当头。
6、zxid
• znode 节点的状态信息中蕴含 czxid, 那么什么是 zxid 呢?
• ZooKeeper 状态的每一次扭转, 都对应着一个递增的 Transaction id, 该 id 称为 zxid. 因为 zxid 的递增性质, 如果 zxid1 小于 zxid2, 那么 zxid1 必定先于 zxid2 产生.
创立任意节点, 或者更新任意节点的数据, 或者删除任意节点, 都会导致 Zookeeper 状态产生扭转, 从而导致 zxid 的值减少.
7、Zookeeper 工作原理
» Zookeeper 的外围是原子播送，这个机制保障了各个 server 之间的同步。实现这个机制的协定叫做 Zab 协定。Zab 协定有两种模式，它们别离是恢复模式和播送模式。
当服务启动或者在领导者解体后，Zab 就进入了恢复模式，当领导者被选举进去，且大多数 server 的实现了和 leader 的状态同步当前，恢复模式就完结了。
状态同步保障了 leader 和 server 具备雷同的零碎状态
» 一旦 leader 曾经和少数的 follower 进行了状态同步后，他就能够开始播送音讯了，即进入播送状态。这时候当一个 server 退出 zookeeper 服务中，它会在恢复模式下启动，
发现 leader，并和 leader 进行状态同步。待到同步完结，它也参加音讯播送。Zookeeper 服务始终维持在 Broadcast 状态，直到 leader 解体了或者 leader 失去了大部分的 followers 反对。
» 播送模式须要保障 proposal 被按程序解决，因而 zk 采纳了递增的事务 id 号 (zxid) 来保障。所有的提议 (proposal) 都在被提出的时候加上了 zxid。
实现中 zxid 是一个 64 为的数字，它高 32 位是 epoch 用来标识 leader 关系是否扭转，每次一个 leader 被选出来，它都会有一个新的 epoch。低 32 位是个递增计数。
» 当 leader 解体或者 leader 失去大多数的 follower，这时候 zk 进入恢复模式，恢复模式须要从新选举出一个新的 leader，让所有的 server 都复原到一个正确的状态。
» 每个 Server 启动当前都询问其它的 Server 它要投票给谁。
» 对于其余 server 的询问，server 每次依据本人的状态都回复本人举荐的 leader 的 id 和上一次处理事务的 zxid（系统启动时每个 server 都会举荐本人）
» 收到所有 Server 回复当前，就计算出 zxid 最大的哪个 Server，并将这个 Server 相干信息设置成下一次要投票的 Server。
» 计算这过程中取得票数最多的的 sever 为获胜者，如果获胜者的票数超过半数，则改 server 被选为 leader。否则，持续这个过程，直到 leader 被选举进去
» leader 就会开始期待 server 连贯
» Follower 连贯 leader，将最大的 zxid 发送给 leader
» Leader 依据 follower 的 zxid 确定同步点
» 实现同步后告诉 follower 曾经成为 uptodate 状态
» Follower 收到 uptodate 音讯后，又能够从新承受 client 的申请进行服务了
8、数据一致性与 paxos 算法
• 据说 Paxos 算法的难了解与算法的知名度一样令人敬佩，所以咱们先看如何保持数据的一致性，这里有个准则就是：
• 在一个分布式数据库系统中，如果各节点的初始状态统一，每个节点都执行雷同的操作序列，那么他们最初能失去一个统一的状态。
• Paxos 算法解决的什么问题呢，解决的就是保障每个节点执行雷同的操作序列。好吧，这还不简略，master 保护一个
全局写队列，所有写操作都必须 放入这个队列编号，那么无论咱们写多少个节点，只有写操作是按编号来的，就能保障一
致性。没错，就是这样，可是如果 master 挂了呢。
• Paxos 算法通过投票来对写操作进行全局编号，同一时刻，只有一个写操作被批准，同时并发的写操作要去争取选票，
只有取得过半数选票的写操作才会被 批准（所以永远只会有一个写操作失去批准），其余的写操作竞争失败只好再发动一
轮投票，就这样，在日复一日年复一年的投票中，所有写操作都被严格编号排 序。编号严格递增，当一个节点承受了一个
编号为 100 的写操作，之后又承受到编号为 99 的写操作（因为网络提早等很多不可预感起因），它马上能意识到本人 数据
不统一了，主动进行对外服务并重启同步过程。任何一个节点挂掉都不会影响整个集群的数据一致性（总 2n+ 1 台，除非挂掉大于 n 台）。
举荐书籍：《从 Paxos 到 Zookeeper 分布式一致性原理与实际》9、Observer
• Zookeeper 需保障高可用和强一致性；
• 为了反对更多的客户端，须要减少更多 Server；
• Server 增多，投票阶段提早增大，影响性能；
• 衡量伸缩性和高吞吐率，引入 Observer
• Observer 不参加投票；
• Observers 承受客户端的连贯，并将写申请转发给 leader 节点；
• 退出更多 Observer 节点，进步伸缩性，同时不影响吞吐率
10、为什么 zookeeper 集群的数目，个别为奇数个？
•Leader 选举算法采纳了 Paxos 协定；
•Paxos 核心思想：当少数 Server 写胜利，则工作数据写胜利如果有 3 个 Server，则两个写胜利即可；如果有 4 或 5 个 Server，则三个写胜利即可。
•Server 数目个别为奇数（3、5、7）如果有 3 个 Server，则最多容许 1 个 Server 挂掉；如果有 4 个 Server，则同样最多容许 1 个 Server 挂掉由此，
咱们看出 3 台服务器和 4 台服务器的的容灾能力是一样的，所以为了节俭服务器资源，个别咱们采纳奇数个数，作为服务器部署个数。
11、Zookeeper 的数据模型
» 层次化的目录构造，命名合乎惯例文件系统标准
» 每个节点在 zookeeper 中叫做 znode, 并且其有一个惟一的门路标识
» 节点 Znode 能够蕴含数据和子节点，然而 EPHEMERAL 类型的节点不能有子节点
» Znode 中的数据能够有多个版本，比方某一个门路下存有多个数据版本，那么查问这个门路下的数据就须要带上版本
» 客户端利用能够在节点上设置监视器
» 节点不反对局部读写，而是一次性残缺读写
12、Zookeeper 的节点
» Znode 有两种类型，短暂的（ephemeral）和长久的（persistent）
» Znode 的类型在创立时确定并且之后不能再批改
» 短暂 znode 的客户端会话完结时，zookeeper 会将该短暂 znode 删除，短暂 znode 不能够有子节点
» 长久 znode 不依赖于客户端会话，只有当客户端明确要删除该长久 znode 时才会被删除
» Znode 有四种模式的目录节点
» PERSISTENT（长久的）
» EPHEMERAL(临时的)
» PERSISTENT_SEQUENTIAL（长久化程序编号目录节点）
» EPHEMERAL_SEQUENTIAL（临时化程序编号目录节点）
