Java大数据平台开发 学习笔记（61）—— Zookeeper、ZAB协议（附 Zookeeper百度云盘下载地址）

一、Zookeeper 简介

1.1、概述

1. Zookeeper是Yahoo!开发后来贡献给了Apache的一套用于进行分布式协调和管理的框架
2. Zookeeper原本是Hadoop的子组件，后来独立出来成为一个单独的顶级项目
3. Zookeeper是一个中心化的服务(注册中心)：统一配置、统一命名、分布式锁(解决了分布式中的死锁>和活锁问题)、分布式组服务
4. Zookeeper是CP系统

1.2、安装方式

• 单机模式：在一台服务器上安装，往往只能启动这个框架的部分服务
• 伪分布式：在一台服务器上安装，通过多个进程来模拟集群环境，能够启动这个框架的部分或者全部的服务 .
• 完全分布式：在集群中安装，能够启动这个集群的所有的服务

1.3、特性

• 过半性：选举过半，操作过半，存活/服务过半
• 一致性：强一致性+最终一致性
• 顺序性：leader按照什么顺序接收的请求，那么follower就会按照什么顺序执行请求 - 队列
• 可靠性：集群不会因为一个节点宕机而停止服务或者产生数据丢失
• 原子性：一个请求要么所有节点都执行要么都不执行
• 实时性：在网络条件较好的情况下，可以对Zookeeper来进行实时监控

1.4、技术细节

1.4.1、特点

1. Zookeeper的默认对外提供的端口号是2181，可以通过zoo.cfg的clientPort来修改
2. Zookeeper本身是一棵树状结构，根节点是/ - Znode树
3. Zookeeper的每一个节点称之为是Znode节点
4. Zookeeper启动之后默认自带一个子节点/zookeeper
5. 要求每一个节点都必须携带数据，这个数据可以是对节点的描述或者是配置信息
6. 在Zookeeper中，所有的路径必须从根节点开始计算
7. Zookeeper会将节点携带的数据维系在内存以及磁盘中
8. 数据在磁盘上的存储位置由dataLogDir属性来决定。如果不指定，那么默认情况下dataLogDir属性和> dataDir属性值一致
9. 在Zookeeper中，会将每一个写操作(connect，create，delete，set等)看作是一个事务，并且会给每一个事务分配一个全局递增的编号，这个编号称之为事务id，简写为Zxid - 事务id就是记录这个整个操作过程中的第几个写操作
10. 临时节点不能挂载子节点

1.4.2、基本命令

1.4.3、节点信息/属性

1.4.4、节点类型

1.5、选举机制

1.5.1、概述

• 在Zookeeper集群启动的时候，所有的节点(服务器)都会进入选举状态，所有的节点都会选举自己成为leader
• 每一个节点都会将自己的选举信息发送给其他的节点，节点之间进行两两比较。经过多轮比较之后，最终胜出的节点就会成为leader

1.5.2、细节

1. 选举信息
   a 当前节点的最大事务id
   b 选举编号 - myid
   c 逻辑时钟值 - 控制选举轮数
2. 比较原则
   a 先比较两个节点的最大事务id，谁大谁赢
   b 如果最大事务id一致，再比较myid，谁大谁赢
   c 如果一个节点胜过一半及以上的节点，这个节点才会成为leader - 过半性
3. Zookeeper集群为了保证稳定性，一旦选举出来leader，那么后来添加的节点的事务id或者myid无论>是多少，都只能成为follower
4. 如果leader丢失，那么剩余的节点会重新选举出来一个新的leader
5. 如果集群出现了2个及以上的leader，称之为脑裂
6. 脑裂产生的条件
   a 集群产生了分裂
   b 集群进行了选举
7. 在Zookeeper集群中，当存活(相互通信)的节点个数不足一半的时候，则剩余的节点不服务(对外停止读写，对内停止选举) - 过半性
8. Zookeeper集群中的节点个数一般是奇数个
9. 在Zookeeper集群中，会对每一次选举出来的leader分配一个全局递增的编号，称之为epochid。当集群中出现多个epochid的时候，会自动的将epochid较小的节点切换为follower状态
10. 在选举状态下，集群暂停对外提供服务
11. Zookeeper集群中节点的状态
    a voting/looking - 选举状态
    b follower - 追随者/跟随者
    c.leader - 领导者
    d.observer - 观察者
12. Zookeeper不是主从结构

1.5.3、observer - 观察者

1. observer既不参与投票(原子广播)也不参与选举，但是observer会监听决策的结果，根据结果来执行对应的操作(如果原子广播决定执行某个操作，observer会跟着而一起干；如果选举出某一个节点成为leader，observer也需要承认这个leader)
2. observer可以看作是没有决策权的follower
3. 在集群规模庞大或者出现异地网络的时候，会将大部分的节点设置为observer
4. 实际生产过程中，会将90%~95%的节点设置为observer。 如果Zookeeper集群中有5个节点；一般是超过7个节点的时候，考虑设置Zookeeper.
5. 考虑过半，考虑的是有决策权的节点数量。如果有1个集群中，有20个节点，包含1个leader+6个follower+13个observer，即使observer全部宕机，集群依然对外服务；如果有4个follower宕机，那么即使observer全部存活，也不会提供服务

---

二、ZAB协议

2.1、概述

ZAB(Zookeeper Atomic Broadcast)是一套专门为Zookeeper设计的用于原子广播和崩溃恢复的协议
ZAB基于2PC算法进行设计，利用了过半性和PAXOS算法进行了改进

2.2、Atomic Broadcast - 原子广播

1. 作用：保证数据一致性。(强一致性+最终一致性)
2. 原子广播基于2PC进行设计的
3. 2PC - Two Phase Commit - 二阶段提交
   a 请求阶段：当协调者收到请求之后，不会立即决定是否要执行这个请求，而是会将请求转发给每一个参与者，等待参与者的反馈信息
   b 提交阶段：如果协调者收到所有参与者返回的yes，那么会认为这个请求可以执行，那么就会命令所有参与者执行这个请求
   c 中止阶段：只要协调者没有收到所有参与者返回的yes，那么就认为这个请求不能执行，就会拒绝执行这个请求
4. 2PC要么执行请求-提交阶段，要么执行请求-中止阶段
5. 2PC的核心思想是"一票否决"
6. 2PC的优势和劣势一样明显。2PC的优势在于理解和实现过程都相对简单；2PC的劣势在于非常受外界环境(尤其是网络环境)影响
7. 在实际开发中，分布式系统很少直接采用2PC算法，而往往都是在2PC的基础上来进行改变。其中Zookeeper的原子广播就是基于2PC加入了过半性来进行改进
8. 原子广播的流程
   a leader接收到请求之后，先把这个请求记录到本地的日志文件log.xxx中。log.xxx文件的位置由dataLogDir属性来决定
   b 如果记录失败，则直接报错；如果记录成功，则leader会将请求放到队列中发送给每一个follower，等待follower的反馈信息
   c follower收到队列之后，会将请求从队列中一一取出，然后记录到本地的日志文件log.xxx中。如果记录成功，则follower会给leader返回一个yes；如果记录失败，则follower会给leader返回一个no
   d 如果leader收到一半及以上的follower返回的yes，则认为这个请求可以执行，那么leader命令所有的节点执行刚才的请求(事务提交)；如果leader没有收到一半的yes，则认为这个请求不能执行，那么leader命令所有的节点删除刚才的请求(事务回滚)
9. 如果follower记录日志失败，但是还需要执行请求的时候，这个时候follower会给leader发送请求，leader收到请求之后，会将请求放到队列中再次发送给follower，follower收到队列之后，会将请求先记录到日志中，然后再执行这个请求。如果这个过程中，日志再次记录失败，则follower会重新发送请求
10. follower返回no的可能 - 日志记录失败
    日志文件被占用
    磁盘已满 - 实际生产过程中，如果磁盘满了，那么一般会进行压缩或者清理
    磁盘损坏
11. 当一个节点重新连入集群之后，这个节点会先寻找自己的最大事务id，然后将自己的事务id发送给leader。 leader在收到请求之后，会比较最大事务id是否一致。如果不一致，则leader会将欠缺的操作放到队列中返回给follower，要求follower补齐事务。在事务补齐期间，这个follower不会对外提供服务

2.3、Fail Over - 崩溃恢复

1. 在Zookeeper中，当leader宕机之后，这个Zookeeper不会停止服务，而是会选举出一个新的leader，这个过程称之为崩溃恢复
2. 作用：保证集群的高可用 - 分区容忍性
3. Zookeeper会给每一个leader分配一个全局递增的编号，称之为epochid。当leader被选举出来之后，这个leader会将自己的epochid分发给每一个follower。每一个follower收到epochid之后，会将这个epochid存储到本地文件acceptedEpoch中
4. 在Zookeeper集群中，事务id实际上由64位二进制(16位十六进制)构成。其中前32位对应的epochid，后32位对应的是实际的事务id。例如事务id为0x400000002表示第4任执行的第2个写操作

---

三、Zookeeper 下载地址

百度云盘链接：https://pan.baidu.com/s/1Ck_gZzWJjVVzUbfQIdsK-w（提取码：122y）
（如果提示过期，请评论再次更新）

---

• 由 ChiKong_Tam 写于 2021 年 1 月 6 日