关于zookeeper:zookeeper学习

canal 利用 zookeeper 进行服务协调，选举主节点，实现零碎的高可用，这里深刻理解 zk，包含个性，实用场景和原理。

概述

Zookeeper 是一个分布式的协调服务。本质是提供了一个相似与 linux 的树形文件系统，客户端可增加子节点，对其赋值，监听节点变动。通过这些操作可实现不同的性能，包含服务发现，选主节点，分布式锁，命名服务等。

概念

节点类型

zk 是一个树形构造，节点具备不同的个性，包含：

• 长期：与客户端会话生命周期雷同，如果客户端断开连接，长期节点被删除。长期节点不可设置子节点
• 永恒：须要手动删除
• 有序：按客户端拜访程序被 zk 调配有序的节点名称。可用于偏心锁的实现。
• 无序

订阅与告诉

客户端可订阅节点，如果该节点被批改，删除或子节点变动，zk 会告诉客户端相应变动。一旦变更被告诉，须要从新设置 watch。
利用 watch 机制可进行主节点选举。多个客户端竞争建设 /leader 长期节点，如果建设失败，订阅 leader 节点。如果主节点挂掉，会话隐没，leader 节点被删除，此时订阅该 leader 的从节点竞争建设 /leader 长期节点，建设胜利的降职为主节点对外提供服务。失败的节点仍监听 leader 节点，负责从节点。利用节点的有序性可实现主节点的偏心选举或偏心锁。

会话

会话即客户端维持与 zk 的一个长连贯。会话期间服务端向客户端收回心跳以表明客户端还存活。如果超时工夫内未检测到心跳，则开释会话，删除客户端建设的长期节点。如果客户端连贯的 zk 节点挂掉，会话会平移到失常提供服务的节点，客户端不会有感知。

事务

zk 会保障客户端的更新要么都胜利，要么都失败

ACL

zk 的权限管制

个性

1. 最终一致性：客户端不论连贯哪个 server，最终会失去同样的视图。即集群内各个节点的状态最终是统一的。因为数据批改时，leader 失去半数以上 follower 的 ack 即 commit，因而有的节点数据更新会滞后，但最终会保持一致。
2. 可靠性：如果音讯被一台机器 commit，最终会被所有机器 commit。如果音讯在一台机器 commit 后，leader 挂掉需从新选举 leader。新 leader 规定是 zxid 最大，即领有最新 commit 数据的节点。
3. 原子性：更新只能胜利或失败，没有中间状态
4. 程序性：一台服务器上音讯 a 在音讯 b 前公布，则在所有 Server 上音讯 a 都将在音讯 b 前被公布；如果音讯 a 在音讯 b 前被同一个发送者公布，则 a 必将排在 b 后面。由 zxid 和队列保障。

这些个性次要有 zab 协定保障。

场景：

• 集群治理，主节点选举
• 分布式锁
• 服务发现
• 配置核心
• 分布式队列

已应用的组件：Hadoop，hbase，dubbo，kafka，canal

ZAB 协定

zab 协定是 zookeeper 原子播送协定，规定了 zk 集群事务申请的解决形式以及如何保证数据一致性。应用 Leader 来接管并解决客户端的更新申请，通过二阶段提交的形式播送至所有的 Follower。当 leader 解体时，由恢复模式不会影响曾经 commit 的数据。任意节点均可解决读申请。
zab 协定次要蕴含两种模式：恢复模式（选主 + 数据恢复）和播送模式（数据同步）。当服务初始化或者 leader 解体后，zookeeper 会进入恢复模式选举 leader，leader 被选举进去后，将本身最新的数据同步至 follower，恢复模式就完结了。播送模式应用 2pc 模式，保障 leader 和 Server 具备雷同的零碎状态。

Zk 具备以下三种角色：

• Leader：一个集群中只有一个 leader，维持和 follower，observer 的心跳，实现写读操作，写完后播送到其余节点
• Follower：实现读申请，将写申请转到 leader，当一段时间接管不到心跳时进入选主状态
• Observer：和 follower 性能类似，但不能选主

zk 解决写申请

zk 解决读申请

原子播送模式：

1. 客户端申请 zk 服务，如果 zk 解决节点不是 leader，则转发到 leader 进行写操作
2. leader 将事务申请转为 proposal 并为其调配全局惟一枯燥递增 zxid
3. leader 为每个 follower 调配独自的队列，将 proposal 放入队列中，按 FIFO 准则异步发送至 follow
4. follower 收到 prososal 后写入本地日志文件，写入胜利后响应 ack 给 leader
5. 当 leader 收到半数 folloer 响应的 ack 后，会认为发送胜利，向 follower 发送 commit 音讯。同时响应给客户端后果
6. follower 收到 commit 后，会提交本地事务，数据更新胜利。

留神：

• 原子播送模式规定 zk 如何解决数据更新事务。相似二阶段事务提交，但不同的是当超过半数 follower ack 后，leader 即认为数据写入胜利并 commit。可进步事务处理的性能。
• Leader 服务器与每一个 Follower 服务器之间都保护了一个独自的 FIFO 音讯队列进行收发音讯，做到异步解耦。如果应用同步的形式会引起阻塞，性能要降落很多。
• Zxid：zk 对客户端的写申请转为 proposal 进行播送，leader 为每次 proposal 调配全局惟一枯燥递增的事务 ID，即 zxid。Zxid 是一个 64 为数字，低 32 位为枯燥递增的计数器，每次事务申请会自增 1。高 32 位为 epoch，代表 leader 周期，每新选举一次 leader，epoch 自增 1 表明进入新的 leader 周期，并将低 32 位清零。follower 只会服从最高 epoch 的 leader。zxid 和 FIFO 队列保障事务的有序性。

恢复模式

会触发恢复模式的场景：

• Leader 宕机
• 集群初始化
• 被分区的两个集群从新合并
• 集群中不存在超过半数的服务器与 Leader 保留失常通信

解体复原流程是主节点选举，数据恢复。
新的主节点要求：

1. 须要保障新的主节点的数据是最新的，即含有最大的 zxid，不能蕴含未提交的 Proposal。之后将数据同步到其余节点，即数据恢复，以确保被一个节点 commit 的数据会被所有节点承受
2. 新选举进去的 Leader 不能蕴含未提交的 Proposal
3. Leader 选举算法不仅仅须要让 Leader 本人晓得本人曾经被选举为 Leader，同时还须要让集群中的所有其余机器也可能疾速感知到选举产生的新 Leader 服务器。

步骤：

1. 选举：Fast Leader Election（疾速选举）。选举领有最新 Proposal history（lastZxid 最大）的节点作为 Leader，成为 Leader 的条件：

   1. 选 epoch 最大的
   2. 若 epoch 相等，选 zxid 最大的
   3. 若 epoch 和 zxid 相等，抉择 server_id 最大的（zoo.cfg 中的 myid）
2. 复原：利用 Leader 最新的 Proposal 历史，同步集群中所有的正本
3. 播送：到了这个阶段，Zookeeper 集群能力正式对外提供事务服务，并且 Leader 能够进行音讯播送。

java 客户端

举荐应用 curator

参考：

zookeeper：
https://www.jianshu.com/p/2bceacd60b8a
https://dbaplus.cn/news-141-1875-1.html
https://draveness.me/zookeeper-chubby/
curator：
https://www.jianshu.com/p/ae0c1fbbff3c