浅谈Zookeeper

简介
一、概述
1. Zookeeper是Apache提供的一套于用进行分布式管理和协调的框架

二、分布式的问题
1. 分布式容易存在死锁以及活锁问题
2. 分布式中,需要引入管理节点
3. 如果只有一个管理节点,容易存在单点故障,所以需要引入管理集群
4. 管理集群中需要选举出一个主节点
5. 管理节点之间需要进行信息的共享

三、安装
1. 单机模式:只用一个节点来安装,往往只能提供这个框架的部分功能
2. 伪分布式:只用一个节点来安装,但是模拟集群环境,能够提供框架的所有功能
3. 完全分布式:在集群中安装,提供这个框架的所有功能

四、特性
1. 过半性
2. 数据一致性 — 原子广播
3. 可靠性 — 崩溃恢复
4. 顺序性 — 队列、epochid
5. 实时性 — 可以对Zookeeper进行实时监控
6. 原子性 — 原子广播

细节
一、特点
1. Zookeeper本身是一个树状结构
2. 根节点是"/"
3. 将Zookeeper中每一个节点称之为znode节点
4. 每一个节点都要求携带数据
5. Zookeeper不支持相对路径
6. 将数据存储在磁盘以及内存中
7. 数据在磁盘上的存储位置由dataDir来决定
8. 理论上Zookeeper可以作为缓存机制使用,但是如果使用Zookeeper作为缓存机制,则会导致内存被大量占用,则致使Zookeeper的协调能力减弱
9. Zookeeper会对每一次的写操作(create/set/delete/rmr)分配一个全局递增的编号,这个编号称之为事务id - Zxid
10. 临时节点不能挂载子节点

二、命令

命令 解释
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 子节点个数

四、节点类型
浅谈Zookeeper_第1张图片
选举机制
一、概述
1. 当Zookeeper在启动的时候,会先去恢复当前服务器上的最大事务id
2. 在选举开始的时候,每一个节点都会选举自己成为leader
3. 每一个Zookeeper服务器会将自己的选举信息发送给其他节点然后进行选举

二、细节
1. 选举信息:
a. 最大事务id
b. 选举编号 - myid
c. 逻辑时钟值 - 控制所有的节点处在同一轮选举上
2. 比较原则:
a. 先比较两个节点之间的最大事务id,谁大谁赢
b. 如果最大事务id一致,则比较myid,myid谁大谁赢
3. 如果一个节点比一半及以上的节点都大,则这个节点会成为leader - 过半性
4. 在Zookeeper中,只要一个集群中选举出来了leader,那么后续新添节点的事务id和myid无论是多少,都只能成为follower
5. 如果leader丢失,会自动重新选举出一个新的leader
6. 因为集群分裂导致子集群产生了leader致使整个集群中产生了多个leader,这个现象称之为脑裂
7. 如果存活的节点个数不足一半的时候,这个Zookeeper集群就不再选举也不再对外提供服务
8. Zookeeper集群的节点个数一般是奇数个
9. Zookeeper中会对每一次选举的leader分配一个全局递增的编号,编号称之为epochid,每一个节点在被选为leader之后,会将当前的epochid分发给每一个follower
10. 如果因为分裂而产生脑裂,恢复之后,Zookeeper会自动kill掉epochid小的那个节点
11. 集群节点状态变化:
a. voting/looking - 选举状态
b. follower - 追随者
c. leader - 领导者
d. observer - 观察者

ZAB协议
一、概述
1. ZAB(Zookeeper Atomic Broadcast) - Zookeeper原子广播协议,是针对Zookeeper专门设计的一套进行原子广播和崩溃恢复的协议
2. ZAB是基于2PC算法进行设计,利用PAXOS算法进行改进

二、原子广播
1. 保证数据一致性 - 访问任意一个节点,获取到的数据都是一样的
2. 基于2PC算法进行了改进,2PC - 2 Phase Commit - 二阶段提交
a. 将提交过程拆分为两个阶段:
i. 准备阶段:当协调者收到请求之后,将请求分发给每一个参与者,并且等待参与者的返回信息
ii. 提交阶段:如果协调者收到了参与者的返回信息,并且所有的参与者都返回了yes,那么协调者发布指令要求执行这个操作
iii. 中止阶段:如果协调者没有收到所有参与者的yes,那么协调者会认为这个操作不能执行,要求所有的参与者删除这个操作
b. 核心思想是"一票否决"

三、崩溃恢复
1. leader从集群中脱离之后,集群会自动选举出一个新的leader
2. 用于避免单点故障
3. 在Zookeeper中,每当产生一个新的leader,会自动分配一个全局递增的epochid,这个epochid同样会体现在Zxid上。在集群中,事务id实际上由64位二进制组成,其中高32位是epochid,低32位是真正的事务id
4. epochid能够有效的保证操作的提交顺序

观察者 - observer
一、概述

1. 特点:不投票不选举,但是会监听投票结果,然后根据投票结果执行操作
2. 观察者适合于节点数量较多或者网络情况不好的场景。在实际开发中,因为参与选举的节点的数量越多选举的效率会越低,所以实际过程中,会将90%的节点设置为observer
3. 因为observer不参与投票,所以observer不影响过半,即observer的存活与否都不会影响集群的服务

通过JAVA代码操作

package cn.tedu.zk;

import java.io.IOException;
import java.util.List;
import java.util.concurrent.CountDownLatch;

import org.apache.zookeeper.CreateMode;
import org.apache.zookeeper.KeeperException;
import org.apache.zookeeper.WatchedEvent;
import org.apache.zookeeper.Watcher;
import org.apache.zookeeper.ZooKeeper;
import org.apache.zookeeper.data.Stat;
import org.apache.zookeeper.Watcher.Event.KeeperState;
import org.apache

你可能感兴趣的:(大数据,zookeeper)