ZooKeeper分布式一致性协调服务框架+过半数存货原则

绝地灬酷狼 2022-04-11 10:48 261阅读 0赞

### zookeeper ###

#### 什么是zookeeper? ####

分布式一致性协调服务框架

换言之,也可以zookeeper看成一个小型的分布式文件系统,  
但是与FastDFS不同,zookeeper只适合用来存储一些小型的数据或者配置信息

提供配置信息管理,命名服务,分布式同步

#### zookeeper安装 ####

1.zookeeper是纯java的所以需要JDK环境  
2.单机安装-配置data/log路径后启动即可

#### zookeeper的文件系统 ####

##### 文件系统的数据结构 #####

zookeeper底层是一个树形结构,用来存储数据

和Linux,Window等系统不同,Linux和Window中有文件和文件夹的概念,文件夹下面才能有文件,文件下面不能有文件,文件夹本身不存放数据,文件本身用来进行数据存储;

zookeeper中的结点,没有文件夹和文件之分,所有结点都可以进行数据存储,同时也可以拥有子节点;

每个结点称之为ZNode

##### ZNode的分类 #####

1.临时节点-ephemeral:  
临时节点由某个客户端创建,如果该客户端断开了和zookeeper服务器的连接,则该临时节点就会自动删除;

###### 注意:临时节点不能有子节点 ######

2.持久性节点-persistent:  
持久化的节点会永久存在于文件系统中,除非客户端显示的删除该节点;该节点是最常见的节点;  
3.顺序节点:  
3.1临时顺序节点-ephemeral\_sequential:  
和临时节点有相同的特点,唯一的区别在于该节点名称会自动维护一个编号  
3.2持久顺序节点-persistent\_sequential:  
和持久化的节点由相同的特点,唯一的区别在于该节点名称会自动维护一个编码

##### zookeeper文件系统操作命令 #####

1…/zkCli.sh ip -p port;  
进入命令行  
[2.ls][] path;  
查看某个路径下的子节点情况,在zookeeper中只能写绝对路径,所有的路径都必须从/出发  
3.create -s(顺序节点) -e(临时节点) path(路径) data(数据) acl(权限);  
创建新节点,数据不能为空  
4.get path;  
查看指定路径对应的节点数据(数据部分+描述部分)  
5.set path data \[version\]  
修改指定节点的数据  
6.delete path data  
删除指定节点的数据

##### Java如何操作zookeeper #####

引入依赖然后,创建 zookeeper对象操作即可

#### zookeeper的通知(watch)机制 ####

##### 什么是通知机制? #####

客户端可以选择对某个ZNode进行监听,当这个ZNode发生变化时(本身的添加删除,修改以及子ZNode的变化),会主动通知监听了这个ZNode的客户端,zookeeper的通知机制有一次性触发原则,ZNode发生变化后,一旦通知了客户端,则断开客户端的监听,如果需要继续监听节点的变化,则必须重新发起监听

##### 监听方法 #####

自定义类MyWatch实现Wathcer接口,实现zookeeper的通知回调方法

//判断abc是否存在,并设置一个监听
    //可以监听到节点创建,节点的内容修改,节点的删除
    //但是不能监听到子节点的变化
    zookeeper.exists("/abc",new MyWatch());
    
    //无法监听到节点的创建,如果abc不存在则报错
    //可以监听当前节点的内容修改,删除
    zookeeper.getData("/abc",new MyWatch(),null);
    
    //无法监听到节点的创建,如果abc不存在则报错
    //无法监听节点本身的变化
    //可以监听子节点的变化,子节点的添加和删除
    //但是不包含内容变化,也不包括孙子节点的变化
    zookeeper.getChildren("/abc",new MyWatch());

##### watch类型 #####

1.数据watch  
exists();  
getData();  
2.孩子watch  
getChildren();

###### 注意:不同的API监听的动作不同 ######

#### 事件类型 ####

None:断开连接  
NodeCreated:t添加  
NodeDeleted:删除  
NodeDataChanged:只和版本号有关  
NodeChildrenChanged:子节点创建或删除

### ZooKeeper的运用场景(重点) ###

##### 1.配置文件统一管理 #####

对分布式系统来说,有很多服务部署在不同的服务器上,不同的服务器有自己一套配置,如果需要配置进行调整,则需要对多台服务器逐个的修改,是不便于管理的

在zookeeper中创建/Configuration持久化节点,将配置信息放在其中  
每个客户端都监听(Watch机制)该持久节点,如果有新的配置信息,开发者只需要上传到zookeeper这个节点上(更新节点的配置数据),一旦节点内容修改,每个应用都会得到zookeeper的通知,然后从中获得新的配置信息,在系统中完成配置更新;

##### 2.集群管理 #####

所谓集群管理无在乎两点:是否有机器退出和加入,选举master

在某些集群中可能需要其他集群服务器的状态,比如有机器加入或退出集群等,这个时候就可以通过zookeeper进行集群的统一管理

所有机器约定在父目录/GroupMembers下创建临时节点,每一个节点就代表一台机器,然后监听父目录节点的子节点的变化消息  
一旦有机器添加和删除,每个机器都会收到通知,接受通知后,每个机器可以在查询节点信息,就可以知道哪个节点添加或者删除,就知道哪个机器进入或退出了,然后进行集群的配置  
master选举的话我们一般通过在父节点创建顺序临时节点,选择编号最小的机器即可

##### 3.分布式锁 #####

实现方式:  
1.保持独占:单进程  
我们把zookeeper上的一个znode看做一把锁,所有的客户端同时创建一个lock临时节点,通过createNode()方法,谁创建成功,谁就获得锁了;业务操作结束后,释放锁删除该节点即可,就算客户端断开临时节点也会删除所以不用担心会形成死锁;  
2.控制时序:加锁排队  
创建一个父节点,所有的客户端在它下面创建顺序临时节点,我们保证编号最小的获得这个锁就可以了

##### 4.命名服务(服务的发现和注册) #####

Dubbo使用的就是这个场景,基于ZooKeeper注册中心,命名服务

假设有一个A服务需要调用B服务,但是AB是两个互相独立的服务,A先完成,B还没有完成  
A就可以主动获得zookeeper某个节点"/name",A就可以不需要再管了,B一旦完成,B直接去"/name"节点上将地址加入其中,A服务就监听到了节点内容的修改,就能够调用该地址

对于集群的负载均衡在父节点下面添加子节点就可以实现

#### Dubbo+ZooKeeper ####

在zookeeper的根目录下有/dubbo节点  
/dubbo节点下面就是我们发布的服务节点  
各个服务节点下面就有我们的服务信息,消费者,提供者,配置信息各种节点…  
服务者节点中就存放了我们需要的调用地址,消费者一旦启动就会去其中获得调用地址,并且消费者也有地址但没有实际作用;

#### ZooKeeper集群,leader-follower ####

ZooKeeper集群由N台机器搭建,这些机器中一定会存在一个leader,其他的机器都是follower,所有客户端都可以随意连接集群中的任一机器;

对于内容修改操作,所有的follower都会收到leader的命令,由leader发起投票,票数超过一半以上则提交命令

#### 集群搭建两种方式 ####

##### 伪集群模式 #####

单机机器中启动多个ZooKeeper进程,并组成集群  
步骤:  
1.将单机装的zookeeper文件复制两份  
2.在zookeeper/data中创建myid文件并编写id编码  
3.修改zookeeper/conf/zoo.cfg核心配置文件port,以及data/log路径,还要配置  
server.1=127.0.0.1:2888:3888  
server.2=127.0.0.2:2889:3889  
server.3=127.0.0.3:2890:3890  
(这两个端口是集群内部通讯的端口)

真实集群就是不需要修改配置port和data路径  
然后配置server的时候ip不一致

4.启动集群  
./zkServer.sh status 查看服务状态,可知道leader/follower角色

##### 集群模式 #####

#### 过半数存活原则 ####

在zookeeper集群中,当存活的机器数量超过总机器的一半的时候,整个集群才能正常工作,否则拒绝访问  
基于过半数存活原则,zookeeper的集群机器数量一定是奇数台,因为2N+1和2N+2的容灾能力是一样的,基于成本考虑2N+1台的选择方案更优

##### 为什么zookeeper需要设计一个过半数存活机制? #####

为了防止网络脑裂,保证数据的强一致性

因为整个集群中,有可能因为网络问题"脑裂",导致整个集群分为2个甚至多个集群,如果没有过半数存活机制,那么整个zookeeper会变成多个集群,那么zookeeper提供的数据无法再保证数据一致性;

#### zookeeper集群角色 ####

1.Leader领导者  
2.Learner学习者:  
Follower跟随者:  
ObServer观察者:功能和追随者一致,响应客户端的命令,不能参加选举和投票环节  
3.Client客户端

#### ZAB协议-原子消息广播协议 ####

ZooKeeper作为高可用的一致性协调框架  
自然的ZooKeeper也有着一致性算法的实现，ZooKeeper使用的是ZAB协议作为数据一致性的算法，ZAB（ZooKeeper Atomic Broadcast ）

#### ZAB基础 ####

Leader选举；  
在ZooKeeper中所有的事务请求都由一个主服务器也就是Leader来处理，其他服务器为Follower，Leader将客户端的事务请求转换为事务Proposal，并且将Proposal分发给集群中其他所有的Follower，然后Leader等待Follwer反馈，当有过半数（>=N/2+1）的Follower反馈信息后，Leader将再次向集群内Follower广播Commit信息，Commit为将之前的Proposal提交；

##### ZAB协议的状态 #####

Looking:选举状态  
Leading:领导状态  
Following:跟随状态

#### zookeeper配置详解 ####

核心配置文件zoo.cfg

###### tickTime：心跳间隔时间,默认为2000ms ######

zookeeper中使用的基本时间单位, 毫秒值。

###### dataDir：数据目录。 ######

修改为zookeeper安装目录下的data目录，data目录自己创建，当然也可以指定为别的目录。

###### initLimit：连接超时时间 ######

Follower初始化连接时和Leader连接的超时时间。默认为10(10 \* 2000ms(tickTime))  
zookeeper集群中的包含多台server，其中一台为leader，其余的server为follower。  
initLimit参数配置初始化连接时，follower和leader之间的最长心跳时间。

###### syncLimit：消息通信超时时间 ######

该参数配置leader和follower之间发送消息，请求和应答的最大时间长度。  
此时该参数设置为2，说明时间限制为2倍tickTime，即4000ms

###### 集群配置详解 ######

server.serverid=serverhost:leader\_listent\_port:quorum\_port

###### serverid：myid ######

是当前zookeeper服务器的id（myid文件中写的编号）。

###### leader\_listen\_port:领导监听端口 ######

通常叫做原子广播端口，是该服务器一旦成为leader之后需要监听的端口,用于接收来自follower的请求。

###### quorum\_port:选举端口 ######

通常叫做选举端口，是集群中的每一个服务器在最开始选举leader时监听的端口,用于服务器互相之间通信选举leader。

[2.ls]: http://2.ls