ZooKeeper简介及原理

简介

一、概述

1. ZooKeeper是由Yahoo（雅虎）开发的，后来提供给Apache管理的一套开源的，用于进行分布式的框架
2. Zookeeper是根据Google的关于Chubby Lock来设计实现的
3. Zookeeper是是一个中心化分布式框架的管理框架
4. zookeeper.out：启动日志，可以查看启动失败原因

二、安装

1. 单机模式：在一台机器上安装，往往只能启动这个框架的一部分的功能
2. 伪分布式：在集群中安装，能够启动这个框架的所有功能
3. 完全分布式：在集群中安装，能启动这个框架的所有功能

基本概念

一、基本理论

1. Zookeeper本身是一个树状结构 - znode树
2. 根结点时/
3. 每一个节点称之为Znode节点
4. 每一个持久节点都可以挂载字节点，每一个临时节点都没有字节点
5. 每一个节点都需要携带数据，这个数据往往是对节点的描述
6. 不存在相对路径的说法,所有节点都需要从/计算
7. zookeeper将数据维系在磁盘以及内存中
   • 维系在内存中的目的是为了快速读写
   • 维系在磁盘中的目的是为了防止奔溃
8. zookeeper在磁盘中存储的位置在dataDir指定
9. 理论上来说，是可以做缓存服务器来使用的 ，但实际开发中不会这么做。因为zookeeper的主要作用作为协调框架来使用的，如果作为缓存服务器使用会占用大量内存,降低zookeeper的协调效率
10. 在节点下不能存在同名节点
11. 在zookeeper中，会讲每一次的写操作看作是一个事务，然后给这个事务分配一个全局递增的编号，称之为事务id，简称Zxid

二、命令

1. ls / 查看根目录的字节点
2. create /video ‘manage video servers’ 创建节点
3. delete / 删除节点下无字节点
4. rmr /video 递归删除
5. set /news ‘manage news servers’ 修改节点信息
6. get /news 获取节点信息
7. create -e /video ‘’ 创建临时节点

三、节点信息

1. cZxid 创建事务id
2. ctime 创建时间
3. mZxid 修改事务id
4. mtime 修改时间
5. pZxid 字节点个数变化的事务id
6. cversion 字节点个数变化的次数
7. dataVersion 数据变化的次数
8. aclVersion 权限变化次数
9. ephemeralOwner 如果节点为临时节点，那么它的值为这个节点拥有者的session ID；如果该节点不是ephemeral节点, ephemeralOwner值为0
10. dataLength 节点数据的长度
11. numChildren 字节点的数目

manage news servers
cZxid = 0x9
ctime = Fri Apr 03 10:44:15 CST 2020
mZxid = 0xa
mtime = Fri Apr 03 10:44:42 CST 2020
pZxid = 0xd
cversion = 3
dataVersion = 1
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 19
numChildren = 3

四、节点类型

• 顺序节点
  1. create -s /news/n ’ ‘ s指的是sequence
• 非顺序节点
  2. create /news/n ‘’

概述

1. 在配置zookeeper的时候，并没有指定那台服务器节点成为leader，那台服务器是follower，但是zookeeper集群启动之后自动出现了leader和follower，那么说明zookeeper在启动过程中出现了选举过程。
2. 在zookeeper集群刚刚启动的时候，这个时候每一个节点都会推荐自己成为leader，并且将自己的选举信息发送给其他节点。
3. 节点之间会两两比较选举信息，比较成功的会进行下一轮选举，经过多轮选举，最终胜出的节点成为leader。

细节

1. 选举信息：
   a. 每一台服务器（节点）的最大事务id
   b. 选举编号 -myid
   c. 逻辑时钟值 -控制节点的选举轮数
2. 比较原则：
   a.先比较两个节点的事务id，谁大谁赢 - 事务id越大，说明接受的写操作越频繁
   b. 如果节点的事务id越大一样，则比较myid，谁大谁赢 - 在zoo.cfg,要求server.x中的x不一致
   c. 一个节点要想成为leader，至少要胜过一半的节点 - 过半性
   d. 在zookeeper集群中为了保证稳定性，一旦确定leader，新加入的节点自动成为follower
   e. 为了避免出现单点故障问题，一旦老leader出现问题，zookeeper集群会自动触发选举机制，会自动选觉一个新的节点成为leader。
   f. 因为集群中出现多个leader，这个现象称之为脑裂
   g.脑裂产生条件
   • 网络产生了分裂/隔离
   • 分裂之后进行了选举
     h. 在zookeeper中，当存活的解ID哪个数不足一半的时候，那么存活的节点之间不选觉也不对外提供服务 - 过半性
     i. 在zookeeper集群中一般把节点个数设置为奇数以满足过半性
     j.在zookeeper集群中选举出leader会分配一个全局递增的编号，也会通知其他节点，称之为epochid。在zookeeper集群中如果出现多个leader，会保留epochid最大的id为leader，同时将其他的leader节点的状态进行切换，切换成follower
     k. 集群中节点的状态
   • voting/looking 选举状态
   • follower 追随者/跟随者
   • leader 领导者
   • observer 观察者
     l.选觉状态下不对外提供服务

ZAB

一、概述

1. ZAB（Zookeeper Atomic Broadcast）是一套专门为zookeeper设计的用于进行原子广播和崩溃恢复的协议。
2. ZAB基于2pc算法来进行设计，利用了过半性和PAXOS算法来进行了改善 - 核心思想：一票否决

二、原子广播

1. 作用：保证数据的一致性 - 在zookeeper中访问任意一个节点获取到的数据都是相同的
2. 原子广播是基于2pc算法来设计的，然后引入过半性来进行改进
3. 2pc - two phase commit -二阶段提交 -实际过程中要么请求-提交，要么请求-中止
   • 请求阶段：协调者收到任务之后，会将任务发给每一个参与者，等待参与者的反馈
   • 调教阶段：如果协调者收到所有参与者的yes，那么协调者要求所有的参与者执行刚才的任务
   • 中止阶段：如果协调者如果没有接受到所有参与者接受请求的信息，就会拒绝这次任务
4. 原子广播的流程：
5. 记录日志失败的可能性
   • 日志文件被占用 - 此时记录的时候却是以只读模式 - 在计算机中，一个文件一旦被某个进程打开其他进程往往以只读模式来打开
   • 磁盘管道损坏
   • 磁盘存储已满
6. 当follower记录日志失败，但是leader却还要求follower执行这个任务的时候，follower就会向leader发送请求，重新获取任务然后leader会将任务放入到队列中发送给follower，重新记录日志；如果再次记录失败，会将重新给leader发送请求重新记录直到成功为止。 - 如果是第一种可能性导致日志记录失败，只要日志未见被释放那么日志就有可能重新记录成功；但是如果是后两种可能，那么就属于硬件环境问题

三、崩溃恢复

1. 作用：避免单点故障，保证集群的高可用
2. 在zookeeper集群中，当leader节点丢失或宕机时，集群不会因为一个节点而不服务，而是会通过选举机制重新选取leader节点，这个过程叫崩溃恢复。
3. 每一个新上任的leader会把自己的epochid分发给每一个follower，follower在收到epochid会把它存储到acceptepochid中。
4. 当一个节点重启炼乳集群之后，这个节点会先寻找当前节点的最大事务id，将自己的最大事务id发送给leader进行比较，如果发现不一致，leader就会将所缺的操作重新放到队列中发送给follower重新补奇，补齐过程中这个follower暂时不会对外提供服务
5. 在集群中，事务id实际上有64位二进制数字（16个十六进制数字）组成，其中高32位代表epochid，低32位代表的是事务id
6. version-2 中log中记录写操作，snap记录整个zookeeper的树结构

四、观察者

1. 观察者的特点：既不参与投票也不参与选举，但是会监听 投票或者选举结果，根据结果来执行对应的操作
2. 在实际开发中，如果集群庞大，为了提高效率，往往将90%的节点设置成observer。如果在异构网络中，也会将绝大部分的节点设置为观察者
3. 在zookeeper中observer不参与选举但是选举出leader之后，观察者听从leader命令；如果leader和follow二决定执行或者不指定某个操作的时候，observer也需要跟着执行或不执行。
4. observer没有投票权和选举权，所以observer是否存活并不影响过半。

五、 特性

1. 过半性：过半选举，过半存活，过半执行
2. 原子性：要么所有的节点都执行请求，要么都不执行
3. 数据一致性：访问任意节点所拿到的数据是一致的
4. 顺序性：leader会讲请求发送到队列中发送给follower，所以保证leader和follower的请求的执行顺序是相同的
5. 实时性：实时监控zookeeper的集群变化
6. 可靠性：奔溃恢复 - 不会因为一个节点当即就导致整个集群不服务

AVRO

一、概述

1. AVRO是由Apache提供的一套用于序列化和RPC的机制
2. AVRO原本是Hadoop的子组件，后来AVRO被独立出来成为了一个顶级项目

二、序列化

1. 序列化实际上是指按照指定的格式将数据转化为其他形式
2. 序列化的作用：为了方便数据的存储和传输
3. 序列化的衡量标准：
   • 序列化花费的时间，占用的资源等
   • 序列化之后产生的数据量的大小
   • 考虑序列化机制本身是否跨平台跨语言
     • 如果数据要在不同的语言之间传输，那么意味着数据要做到数据与语言无关
     • 数字，布尔值，字符/字符串
     • 字符/字符串与编码有关-只要两种计算机语言用同一套码表就可以进行数据的传输
4. 实际开发过程中，绝大部分的序列化机制都考虑转化为字符串-AVRO实际就是将对象转化为jason

三、RPC

1. RPC(Remote Procedure Call,远程过程调用)允许程序员在一个节点（服务器）上去远程调用另一个节点上的方法而不用显示的实现这个方法
2. 特点：简单，高效，通用
3. RPC的stub（存根）就是限制不同的节点上的方法签名是一致的，在Java中一般用接口