- 概述：Zookeeper是Apache提供的一套于用进行分布式管理和协调的框架
- 分布式存在的问题：
- 分布式容易存在死锁以及活锁问题
- 分布式中，需要引入管理节点
- 如果只有一个管理节点，容易存在单点故障，所以需要引入管理集群
- 管理集群中需要选举出一个主节点
- 管理节点之间需要进行信息的共享
- 安装：
- 单机模式：只用一个节点来安装，往往只能提供这个框架的部分功能
- 伪分布式：只用一个节点来安装，但是模拟集群环境，能够提供框架的所有功能
- 完全分布式：在集群中安装，提供这个框架的所有功能
- 特点：
- Zookeeper本身是一个树状结构
- 根节点是/
- 将Zookeeper中称之为znode节点
- 每一个节点都要求携带数据
- Zookeeper不支持相对路径
- 将数据存储在磁盘以及内存中
- 数据在磁盘上的存储位置由dataDir来决定
- 理论上Zookeeper可以作为缓存机制使用，但是如果使用Zookeeper作为缓存机制，则会导致内存被大量占用，则致使Zookeeper的协调能力减弱
- Zookeeper会对每一次的写操作（create/set/delete/rmr）分配一个全局递增的编号，这个编号称之为事务id - Zxid
- 临时节点不能挂载子节点
- 命令：
命令 | 解释 |
ls / | 查看根节点的所有子节点 |
create /news 'news server' | 创建节点 |
delete /log | 删除节点。要求这个节点没有子节点 |
rmr /news | 递归删除 |
set /log 'log servers' | 更新数据 |
get /log | 查看数据 |
- 节点信息
属性 | 解释 |
cZxid | 创建事务id - create |
ctime | 创建时间 |
mZxid | 修改事务id - set |
mtime | 修改时间 |
pZxid | 子节点个数变化事务id |
cversion | 子节点个数变化次数 |
dataVersion | 数据变化次数 |
aclVersion | 权限变化次数 |
ephemeralOwner | 用于标记当前节点是否是一个临时节点 如果是持久节点，此项为0 如果是临时节点，此项的值是sessionid |
dataLength | 数据的字节个数 |
numChildren | 子节点个数 |
- 节点类型
| 持久节点 | 临时节点 |
顺序节点 | Persistant_Sequencial | Ephemeral_Sequencial |
非顺序节点 | Persistant | Ephemeral |
- 选举机制
- 概述：
- 当Zookeeper在启动的时候，会先去恢复当前服务器上的最大事务id
- 在选举开始的时候，每一个节点都会选举自己成为leader
- 每一个Zookeeper服务器会将自己的选举信息发送给其他节点然后进行选举
- 细节：
- 选举信息：
- 最大事务id
- 选举编号 - myid
- 逻辑时钟值 - 控制所有的节点处在同一轮选举上
- 比较原则：
- 先比较两个节点之间的最大事务id，谁大谁赢
- 如果最大事务id一致，则比较myid，myid谁大谁赢
- 如果一个节点比一半及以上的节点都大，则这个节点会成为leader - 过半性
- 在Zookeeper中，只要一个集群中选举出来了leader，那么后续新添节点的事务id和myid无论是多少，都只能成为follower
- 如果leader丢失，会自动重新选举出一个新的leader
- 因为集群分裂导致子集群产生了leader致使整个集群中产生了多个leader，这个现象称之为脑裂
- 如果存活的节点个数不足一半的时候，这个Zookeeper集群就不再选举也不再对外提供服务
- Zookeeper集群的节点个数一般是奇数个
- Zookeeper中会对每一次选举的leader分配一个全局递增的编号，编号称之为epochid，每一个节点在被选为leader之后，会将当前的epochid分发给每一个follower
- 如果因为分裂而产生脑裂，恢复之后，Zookeeper会自动kill掉epochid小的那个节点
- 集群节点状态变化：
- voting/looking - 选举状态
- follower - 追随者
- leader - 领导者
- observer - 观察者
- ZAB协议：
- 概述
- ZAB(Zookeeper Atomic Broadcast) - Zookeeper原子广播协议，是针对Zookeeper专门设计的一套进行原子广播和崩溃恢复的协议
- 基于2PC算法进行了改进，2PC - 2 Phase Commit - 二阶段提交
- 将提交过程拆分为两个阶段：
- 准备阶段：当协调者收到请求之后，将请求分发给每一个参与者，并且等待参与者的返回信息
- 提交阶段：如果协调者收到了参与者的返回信息，并且所有的参与者都返回了yes，那么协调者发布指令要求执行这个操作
- 中止阶段：如果协调者没有收到所有参与者的yes，那么协调者会认为这个操作不能执行，要求所有的参与者删除这个操作
- 核心思想是"一票否决"
- 原子广播：
- 保证数据一致性-访问任意一个节点，获取到的数据都是一样的
- 基于2PC算法进行了改进
- leader 在 收 到 请 求 之后， 先 将 这 个 请 求 记 录 到 日 志 中 ， 如 果 记 录 成 功 ， 则 leader 会 认 为 这 个 请 求 可 以 执行， 然 后 leader 会 将 请 求 放 入 队 列 中 发 送 给 每 一 个 follower ， 等 待 的follower 的 返 回 信 息 follower 在 收 到 队 列 之后 ， 将 队 列 中 的 请 求 一 一 取 出 来 写 到 本 地 的 日 志 文件 中 如 果 记 录 成 功 ， 则 follower 会 给 leader 返 回 yes 信 号 ， 认 为 这 个 请 求 可 以 执 行 如 果 有 半 数 及 以 上 的 follower 返 回 了 yes ， 则 leader 会 认 为 这 个 请 求 可 以 执 行 ， 会 给 follower 发 送 信 息 要 求 执 行 这 个 请 求 如 果 记 录 失 败 ， 则 follower 会 给 leader 返 回 no 信 号 ， 认 为 这 个 请 求 不 能 执 行 如 果 leader 没 有 收 到 半 数 的 yes ， 会 认 为 这 个 请 求 不 能 执 行 ， 会 给 follower 发 送 指 令 要 求 删 除 这 个 请 求
- 崩溃修复：
- leader从集群中脱离之后，集群会自动选举出一个新的leader
- 用于避免单点故障
- 在Zookeeper中，每当产生一个新的leader，会自动分配一个全局递增的epochid，这个epochid同样会体现在Zxid上。在集群中，事务id实际上由64位二进制组成，其中高32位是epochid，低32位是真正的事务id
- epochid能够有效的保证操作的提交顺序
- 观察者：observer
- 特点：不投票不选举，但是会监听投票结果，然后根据投票结果执行操作
- 观察者适合于节点数量较多或者网络情况不好的场景。在实际开发中，因为参与选举的节点的数量越多选举的效率会越低，所以实际过程中，会将90%的节点设置为observer
- 因为observer不参与投票，所以observer不影响过半，即observer的存活与否都不会影响集群的服务
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
