概念
概述
Zookeeper 是一个开源的分布式的,为分布式框架提供协调服务的 Apache 项目。
zookeeper工作机制
Zookeeper从设计模式角度来理解:是一个基于观察者模式设计的分布式服务管理框架,它负责 存储和管理大家都关心的数据
,然后接受观察者的注册
,一旦这些数据的状态发生变化,Zookeeper 就将负责通知已经在Zookeeper上注册的那些观察者
做出相应的反应。
zookeeper主要是文件系统
和通知机制
-
文件系统主要是用来存储数据
-
通知机制主要是服务器或者客户端进行通知,并且监督
基于观察者模式设计的分布式服务管理框架,开源的分布式框架
特点
-
一个leader,多个follower的集群
-
集群只要有半数以上包括半数就可正常服务,一般安装奇数台服务器
-
全局数据一致,每个服务器都保存同样的数据,实时更新
-
更新的请求顺序保持顺序(来自同一个服务器)
-
数据更新的原子性,数据要么成功要么失败
-
数据实时更新性很快
主要的集群步骤为
-
服务端启动时去注册信息(创建都是临时节点)
-
获取到当前在线服务器列表,并且注册监听
-
服务器节点下线
-
服务器节点上下线事件通知
-
process(){重新再去获取服务器列表,并注册监听}
数据结构
与 Unix 文件系统很类似
,可看成树形结构,每个节点称做一个 ZNode
。每一个 ZNode 默认能够存储1MB
的数据。也就是只能存储小数据
应用场景
-
统一命名服务(域名服务)
在分布式环境下,经常需要对应用/服务进行统一命名,便于识别。例如:IP不容易记住,而域名容易记住
-
统一配置管理(一个集群中的所有配置都一致,且也要实时更新同步) 将配置信息写入ZooKeeper上的一个Znode,各个客户端服务器监听这个Znode。一旦Znode中的数据被修改,ZooKeeper将通知各个客户端服务器
-
统一集群管理(掌握实时状态) 将节点信息写入ZooKeeper上的一个ZNode。监听ZNode获取实时状态变化
-
服务器节点动态上下线
-
软负载均衡(根据每个节点的访问数,让访问数最少的服务器处理最新的数据需求)
安装
bin
目录 框架启动停止,客户端和服务端的 conf
配置文件信息 docs
文档 lib
配置文档的依赖
具体安装的文档可查看我这篇文章 Zookeeper的安装配置详解(window / linux) 如果中途出现问题,可参考这篇文章
安装前准备
(1)安装 JDK (2)拷贝 apache-zookeeper-3.5.7-bin.tar.gz 安装包到 Linux 系统下 (3)解压到指定目录
tar -zxvf apache-zookeeper-3.5.7-bin.tar.gz -C /opt/module/
(4)修改名称
mv apache-zookeeper-3.5.7-bin zookeeper-3.5.7
配置修改
(1)将/opt/module/zookeeper-3.5.7/conf 这个路径下的 zoo_sample.cfg 修改为 zoo.cfg;
mv zoo_sample.cfg zoo.cfg
(2)打开 zoo.cfg 文件,修改 dataDir 路径:
vim zoo.cfg 修改如下内容: dataDir=/opt/module/zookeeper-3.5.7/zkData
(3)在/opt/module/zookeeper-3.5.7/这个目录上创建 zkData 文件夹
mkdir zkData
操作zookeeper
(1)启动 Zookeeper
bin/zkServer.sh start
(2)查看进程是否启动
jps 显示: 4020 Jps 4001 QuorumPeerMain
(3)查看状态
bin/zkServer.sh status 显示: ZooKeeper JMX enabled by default Using config: /opt/module/zookeeper-3.5.7/bin/../conf/zoo.cfg Mode: standalone
(4)启动客户端
bin/zkCli.sh
(5)退出客户端:
quit
(6)停止 Zookeeper
bin/zkServer.sh stop
配置文件解读
配置文件的5大参数
-
tickTime = 2000
发送时间 -
initLimit = 10
初始化通信的时间,最多不能超过的时间,超过的话,通信失败 -
syncLimit = 5
建立好连接后,下次的通信时间如果超过,通信失败 -
dataDir
保存zookeeper的数据,默认是temp会被系统定期清除 -
clientPort = 2181
客户端的连接端口,一般不需要修改
zookeeper集群操作
集群安装
比如三个节点部署zookeeper,那么需要3台服务器
安装步骤
-
解压安装zookeeper
-
配置服务器编号
-
在/opt/zookeeper-3.5.7/这个目录下创建 zkData
-
在/opt/zookeeper-3.5.7/zkData 目录下创建一个 myid 的文件
在文件中添加与 server 对应的编号(注意:上下不要有空行,左右不要有空格)
2
-
-
拷贝配置好的 zookeeper 到其他机器上,并分别在 hadoop103、hadoop104 上修改 myid 文件中内容为 3、4
xsync zookeeper-3.5.7
-
修改zoo.cfg文件
-
重命名/opt/module/zookeeper-3.5.7/conf 这个目录下的 zoo_sample.cfg 为 zoo.cfg
mv zoo_sample.cfg zoo.cfg
-
修改数据存储路径配置,并在最后面添加如下配置
dataDir=/opt/module/zookeeper-3.5.7/zkData server.2=hadoop102:2888:3888 server.3=hadoop103:2888:3888 server.4=hadoop104:2888:3888
-
同步zoo.cfg 配置文件
xsync zoo.cfg
-
-
集群操作
-
分别启动zookeeper
bin/zkServer.sh start
-
查看状态
bin/zkServer.sh status
-
集群成功启动后的效果:
配置文件解读
当前主要配置编号的参数是server.A=B:C:D
-
A标识第几台服务器
-
B标识服务器地址
-
C标识服务器 Follower 与集群中的 Leader 服务器交换信息的端口
-
D主要是选举,如果Leader 服务器挂了。这个端口就是用来执行选举时服务器相互通信的端口,通过这个端口进行重新选举leader
配置文件以及服务器编号设置好后即可启动
选举机制
以下主要是面试的重点 区分好第一次启动与非第一次启动的步骤 epoch在没有leader的时候,主要是逻辑时钟(与数字电路中的逻辑时钟相同)
非第一次启动,在没有leader的时候 其判断依据是:epoch任职期>事务id>服务器sid
集群启动停止脚本
如果服务器太多,需要一台一台启动和关闭会比较麻烦
脚本文件大致如下: 建立一个后缀名为zk.sh的文件
#!/bin/bash case $1 in "start"){ for i in hadoop102 hadoop103 hadoop104 do echo ---------- zookeeper $i 启动 ------------ ssh $i "/opt/module/zookeeper-3.5.7/bin/zkServer.sh start" done };; "stop"){ for i in hadoop102 hadoop103 hadoop104 do echo ---------- zookeeper $i 停止 ------------ ssh $i "/opt/module/zookeeper-3.5.7/bin/zkServer.sh stop" done };; "status"){ for i in hadoop102 hadoop103 hadoop104 do echo ---------- zookeeper $i 状态 ------------ ssh $i "/opt/module/zookeeper-3.5.7/bin/zkServer.sh status" done };; esac
修改该文件的权限:
通过chmod 777 zk.sh
,之后在一个服务器中执行./zk.sh start
就可启动脚本文件,其它命令也如此
查看其进程号: 可以通过jpsall
就可查看所有服务器的进程
客户端命令
常用命令
命令 | 功能 |
---|---|
help | 显示所有操作命令 |
ls path | 使用 ls 命令来查看当前 znode 的子节点 [可监听] ,-w 监听子节点变化,-s 附加次级信息 |
create | 普通创建 |
-s | 含有序列 |
-e | 临时(重启或者超时消失) |
get path | 获得节点的值 [可监听] ,-w 监听节点内容变化 |
-s | 附加次级信息 |
set | 设置节点的具体值 |
stat | 查看节点状态 |
delete | 删除节点 |
deleteall | 递归删除节点 |
通过ls /
查看当前znode包含的信息
[zk: localhost:2181(CONNECTED) 0] ls / [zookeeper] 123
查看当前数据节点详细信息ls -s /
名称 | 表述 |
---|---|
czxid | 创建节点的事务 zxid,每次修改 ZooKeeper 状态都会产生一个 ZooKeeper 事务 ID。事务 ID 是 ZooKeeper 中所有修改总的次序。每次修改都有唯一的 zxid,如果 zxid1 小于 zxid2,那么 zxid1 在 zxid2 之前发生。 |
ctime | znode 被创建的毫秒数(从 1970 年开始) |
mzxid | znode 最后更新的事务 zxid |
mtime | znode 最后修改的毫秒数(从 1970 年开始) |
pZxid | znode 最后更新的子节点 zxid |
cversion | znode 子节点变化号,znode 子节点修改次数 |
dataversion | znode 数据变化号 |
aclVersion | znode 访问控制列表的变化号 |
ephemeralOwner | 如果是临时节点,这个是 znode 拥有者的 session id。如果不是临时节点则是 0 |
dataLength | znode 的数据长度 |
numChildren | znode 子节点数量 |
启动客户端的时候默认是本地的localhost
如果要启动专门的服务器 启动客户端的时候后缀要加上./zkCli.sh -server 服务器名:2181
博主的启动方式也为./zkCli.sh -server hadoop102:2181
节点类型
节点类型分为(两两进行组合)
-
持久/短暂
-
有序号/无序号
-
创建永久节点不带序号的
-
创建永久节点带序号的(-s)
通过加上
-s
参数,即便创建两个一样的,-s
自动会加上序号辨别两者不同退出客户端之后,这些节点并没有被清除
-
创建临时节点 加上参数
-e
,如果要带上节点序号则加上-s
,如果退出客户端,这些短暂节点将会被清除
如果修改节点的值,通过set key value
即可
监听器原理
注册一次监听一次 主要有节点值的变化还有节点路径的变化 在一个服务器中通过修改其值或者路径 在另一个服务器中进行监听,通过
get -w 节点值
进行监听节点值的变化 如果是路径的变化,在另一个服务器中进行ls -w 路径
进行监听
如果有很多个节点 不能直接使用删除delete
需要删除deleteall
查看节点的状态信息 stat
客户端监听操作
(1)节点的值变化监听
-
在 hadoop104 主机上注册监听/sanguo 节点数据变化
[zk: localhost:2181(CONNECTED) 26] get -w /sanguo
-
在 hadoop103 主机上修改/sanguo 节点的数据
[zk: localhost:2181(CONNECTED) 1] set /sanguo "xisi"
-
观察 hadoop104 主机收到数据变化的监听
WATCHER:: WatchedEvent state:SyncConnected type:NodeDataChanged path:/sanguo
注意:在hadoop103再多次修改/sanguo的值,hadoop104上不会再收到监听。因为注册一次,只能监听一次。想再次监听,需要再次注册。
(2)节点的子节点变化监听(路径变化)
-
在 hadoop104 主机上注册监听/sanguo 节点的子节点变化
[zk: localhost:2181(CONNECTED) 1] ls -w /sanguo [shuguo, weiguo]
-
在 hadoop103 主机/sanguo 节点上创建子节点
[zk: localhost:2181(CONNECTED) 2] create /sanguo/jin "simayi" Created /sanguo/jin
-
观察 hadoop104 主机收到子节点变化的监听
WATCHER:: WatchedEvent state:SyncConnected type:NodeChildrenChanged path:/sanguo
注意:节点的路径变化,也是注册一次,生效一次。想多次生效,就需要多次注册。
(3)节点删除与查看
-
删除节点
[zk: localhost:2181(CONNECTED) 4] delete /sanguo/jin
-
递归删除节点
[zk: localhost:2181(CONNECTED) 15] deleteall /sanguo/shuguo
-
查看节点状态
[zk: localhost:2181(CONNECTED) 17] stat /sanguo cZxid = 0x100000003 ctime = Wed Aug 29 00:03:23 CST 2018 mZxid = 0x100000011 mtime = Wed Aug 29 00:21:23 CST 2018 pZxid = 0x100000014 cversion = 9 dataVersion = 1 aclVersion = 0 ephemeralOwner = 0x0 dataLength = 4 numChildren = 1
客户端监听代码操作
-
创建一个工程
-
在pom文件中配好依赖文件
<dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>RELEASE</version> </dependency> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-core</artifactId> <version>2.8.2</version> </dependency> <dependency> <groupId>org.apache.zookeeper</groupId> <artifactId>zookeeper</artifactId> <version>3.5.7</version> </dependency> </dependencies>
-
需要在项目的 src/main/resources 目录下,新建一个文件,命名为“log4j.properties”,在 文件中填入
log4j.rootLogger=INFO, stdout log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.layout=org.apache.log4j.PatternLayout log4j.appender.stdout.layout.ConversionPattern=%d %p [%c] - %m%n log4j.appender.logfile=org.apache.log4j.FileAppender log4j.appender.logfile.File=target/spring.log log4j.appender.logfile.layout=org.apache.log4j.PatternLayout log4j.appender.logfile.layout.ConversionPattern=%d %p [%c] - %m%n
-
在客户端中生成具体代码
初始化并且负责监听节点,主要通过设置连接的服务器,以及超时参数,监听匿名函数new Watcher() {}
// 注意:逗号左右不能有空格 private String connectString = "hadoop102:2181,hadoop103:2181,hadoop104:2181"; private int sessionTimeout = 2000; private ZooKeeper zkClient; @Before public void init() throws IOException { zkClient = new ZooKeeper(connectString, sessionTimeout, new Watcher() { @Override public void process(WatchedEvent watchedEvent) { }); } }
(1)创建一个新的节点 创建的节点必须在初始化节点这些之后,通过注解,在之前中加入before
-
第一个参数是路径
-
第二个参数是数据,要求是字节类型,需要用
getBytes()
-
第三个参数是权限,
Ids.OPEN_ACL_UNSAFE
允许所有人进行访问 -
第四个参数是创建节点的类型
@Test public void create() throws KeeperException, InterruptedException { String nodeCreated = zkClient.create("/manongyanjiuseng ", "123".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT); 123
(2)获取子节点并且监听其变化 获取子节点通过getChildren()
,关于获取子节点一共有两种 获取子节点第一个是路径,第二个是监听函数,如果使用true,则会使用初始化函数中重写的监听函数
@Test public void getChildren() throws KeeperException, InterruptedException { List<String> children = zkClient.getChildren("/", true); for (String child : children) { System.out.println(child); } // 延时 Thread.sleep(Long.MAX_VALUE); }
注册一次生效一次,还需要再进行注册,如果希望通过延迟函数延迟程序的结束,继续放在监听函数中就可以注册一次生效一次,之后再注册就可以实时监听节点的增减
zkClient = new ZooKeeper(connectString, sessionTimeout, new Watcher() { @Override public void process(WatchedEvent watchedEvent) { System.out.println("-------------------------------"); List<String> children = null; try { children = zkClient.getChildren("/", true); for (String child : children) { System.out.println(child); } System.out.println("-------------------------------"); } catch (KeeperException e) { e.printStackTrace(); } catch (InterruptedException e) { e.printStackTrace(); } } });
[zk: localhost:2181(CONNECTED) 12] create /atguigu1 "jishu2" Created /atguigu1 [zk: localhost:2181(CONNECTED) 13] delete /atguigu1 打印结果: NodeChildrenChanged--/ atguigu1 zookeeper atguigu NodeChildrenChanged--/ zookeeper atguigu
(3)判断Znode节点是否存在 exits函数,返回的是状态信息,通过状态信息判断是否还在 第一个参数是路径 第二个参数是是否监听
@Test public void exist() throws KeeperException, InterruptedException { Stat stat = zkClient.exists("/manongyanjiuseng", false); System.out.println(stat==null? "not exist " : "exist"); }
客户端向服务端写数据流程
-
发送给leader的时候 通俗解释:客户端给服务器的leader发送写请求,写完数据后给手下发送写请求,手下写完发送给leader,超过半票以上都写了则发回给客户端。之后leader在给其他手下让他们写,写完在发数据给leader
-
发送给follower的时候 通俗解释:客户端给服务器的follower发送写的请求,follower给leader发送写的请求,写完后,给手下发送写的请求,手下写完后给leader发送确认,超过半票,leader确认后,发给确认给follower,然后follower响应客户端请求,最后leader再发送写请求给其他手下
服务器动态上下线监听
-
服务器上线的时候其实就是服务器启动时去注册信息(创建的都是临时节点)
-
客户端获取到当前在线的服务器列表后
-
服务器节点下线后给集群管理
-
集群管理服务器节点的下件时间通知给客户端
-
客户端通过获取服务器列表新选择服务器
-
服务器代码
-
获取zookeeper集群的连接,通过zookeeper的构造函数
ZooKeeper(connectString, sessionTimeout, new Watcher(){})
-
将其服务注册到zookeeper集群中,具体通过
create的函数
,通过获取每个服务器名字、其值、权限、节点类型 -
执行该函数通过延迟函数
public class DistributeServer { private String connectString = "hadoop102:2181,hadoop103:2181,hadoop104:2181"; private int sessionTimeout = 2000; private ZooKeeper zk; public static void main(String[] args) throws IOException, KeeperException, InterruptedException { DistributeServer server = new DistributeServer(); // 1 获取zk连接 server.getConnect(); // 2 注册服务器到zk集群 server.regist(args[0]); // 3 启动业务逻辑(睡觉) server.business(); } private void business() throws InterruptedException { Thread.sleep(Long.MAX_VALUE); } private void regist(String hostname) throws KeeperException, InterruptedException { String create = zk.create("/servers/"+hostname, hostname.getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL); System.out.println(hostname +" is online") ; } private void getConnect() throws IOException { zk = new ZooKeeper(connectString, sessionTimeout, new Watcher() { @Override public void process(WatchedEvent watchedEvent) { } }); } }
-
客户端代码
-
获取zookeeper集群的连接,通过zookeeper的构造函数
ZooKeeper(connectString, sessionTimeout, new Watcher(){})
-
客户端通过监听每个节点,具体监听通过
getChildren
函数,获取其节点位置,以及是否使用初始化的监听函数,true为使用。获取到的都是以列表存在,输出的时候通过遍历实现,输出的还是一些数组格式。将这些数组都封装到一个列表中,最后统一输出列表即可 -
执行该函数通过延迟函数
因为注册的时候记录一次,所以在初始化的时候,将其注册放在初始化内部getServerList();
public class DistributeClient { private String connectString = "hadoop102:2181,hadoop103:2181,hadoop104:2181"; private int sessionTimeout = 2000; private ZooKeeper zk; public static void main(String[] args) throws IOException, KeeperException, InterruptedException { DistributeClient client = new DistributeClient(); // 1 获取zk连接 client.getConnect(); // 2 监听/servers下面子节点的增加和删除 client.getServerList(); // 3 业务逻辑(睡觉) client.business(); } private void business() throws InterruptedException { Thread.sleep(Long.MAX_VALUE); } private void getServerList() throws KeeperException, InterruptedException { List<String> children = zk.getChildren("/servers", true); ArrayList<String> servers = new ArrayList<>(); for (String child : children) { byte[] data = zk.getData("/servers/" + child, false, null); servers.add(new String(data)); } // 打印 System.out.println(servers); } private void getConnect() throws IOException { zk = new ZooKeeper(connectString, sessionTimeout, new Watcher() { @Override public void process(WatchedEvent watchedEvent) { try { getServerList(); } catch (KeeperException e) { e.printStackTrace(); } catch (InterruptedException e) { e.printStackTrace(); } } }); } }
具体测试的逻辑:
-
启动客户端,通过虚拟机进行create -e -s 节点信息(临时带序号的节点),或者delete进行更新
-
启动服务器,判定节点是否正常上下线
分布式锁
分布式锁:
比如说"进程 1"在使用该资源的时候,会先去获得锁,"进程 1"获得锁以后会对该资源保持独占,这样其他进程就无法访问该资源,"进程 1"用完该资源以后就将锁释放掉,让其他进程来获得锁,那么通过这个锁机制,我们就能保证了分布式系统中多个进程能够有序的访问该临界资源。那么我们把这个分布式环境下的这个锁叫作分布式锁。
原生zookeeper分布式锁
实现原理:
创建节点,判断是否是最小的节点,如果不是最小的节点,需要监听前一个的节点
健壮性可以通过CountDownLatch类
监听函数 如果集群状态是连接,则释放connectlatch 如果集群类型是删除,且前一个节点的位置等于该节点的文职,则释放该节点
判断节点是否存在不用一直监听,获取节点信息要一直监听getData
public class DistributedLock { private final String connectString = "hadoop102:2181,hadoop103:2181,hadoop104:2181"; private final int sessionTimeout = 2000; private final ZooKeeper zk; private CountDownLatch connectLatch = new CountDownLatch(1); private CountDownLatch waitLatch = new CountDownLatch(1); private String waitPath; private String currentMode; public DistributedLock() throws IOException, InterruptedException, KeeperException { // 获取连接 zk = new ZooKeeper(connectString, sessionTimeout, new Watcher() { @Override public void process(WatchedEvent watchedEvent) { // connectLatch 如果连接上zk 可以释放 if (watchedEvent.getState() == Event.KeeperState.SyncConnected){ connectLatch.countDown(); } // waitLatch 需要释放 if (watchedEvent.getType()== Event.EventType.NodeDeleted && watchedEvent.getPath().equals(waitPath)){ waitLatch.countDown(); } } }); // 等待zk正常连接后,往下走程序 connectLatch.await(); // 判断根节点/locks是否存在 Stat stat = zk.exists("/locks", false); if (stat == null) { // 创建一下根节点 zk.create("/locks", "locks".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT); } } // 对zk加锁 public void zklock() { // 创建对应的临时带序号节点 try { currentMode = zk.create("/locks/" + "seq-", null, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL); // wait一小会, 让结果更清晰一些 Thread.sleep(10); // 判断创建的节点是否是最小的序号节点,如果是获取到锁;如果不是,监听他序号前一个节点 List<String> children = zk.getChildren("/locks", false); // 如果children 只有一个值,那就直接获取锁; 如果有多个节点,需要判断,谁最小 if (children.size() == 1) { return; } else { Collections.sort(children); // 获取节点名称 seq-00000000 String thisNode = currentMode.substring("/locks/".length()); // 通过seq-00000000获取该节点在children集合的位置 int index = children.indexOf(thisNode); // 判断 if (index == -1) { System.out.println("数据异常"); } else if (index == 0) { // 就一个节点,可以获取锁了 return; } else { // 需要监听 他前一个节点变化 waitPath = "/locks/" + children.get(index - 1); zk.getData(waitPath,true,new Stat()); // 等待监听 waitLatch.await(); return; } } } catch (KeeperException e) { e.printStackTrace(); } catch (InterruptedException e) { e.printStackTrace(); } } // 解锁 public void unZkLock() { // 删除节点 try { zk.delete(this.currentMode,-1); } catch (InterruptedException e) { e.printStackTrace(); } catch (KeeperException e) { e.printStackTrace(); } } }
测试类:
public class DistributedLockTest { public static void main(String[] args) throws InterruptedException, IOException, KeeperException { final DistributedLock lock1 = new DistributedLock(); final DistributedLock lock2 = new DistributedLock(); new Thread(new Runnable() { @Override public void run() { try { lock1.zklock(); System.out.println("线程1 启动,获取到锁"); Thread.sleep(5 * 1000); lock1.unZkLock(); System.out.println("线程1 释放锁"); } catch (InterruptedException e) { e.printStackTrace(); } } }).start(); new Thread(new Runnable() { @Override public void run() { try { lock2.zklock(); System.out.println("线程2 启动,获取到锁"); Thread.sleep(5 * 1000); lock2.unZkLock(); System.out.println("线程2 释放锁"); } catch (InterruptedException e) { e.printStackTrace(); } } }).start(); } }
测试结果: 线程 1 获取锁 线程 1 释放锁 线程 2 获取锁 线程 2 释放锁
curator分布式锁
原生的 Java API 开发存在的问题 (1)会话连接是异步的,需要自己去处理。比如使用CountDownLatch (2)Watch 需要重复注册,不然就不能生效 (3)开发的复杂性还是比较高的 (4)不支持多节点删除和创建。需要自己去递归
详情请查看官方文档:https://curator.apache.org/index.html
curator可以解决上面的问题
添加相关的依赖文件
<dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-framework</artifactId> <version>4.3.0</version> </dependency> <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-recipes</artifactId> <version>4.3.0</version> </dependency> <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-client</artifactId> <version>4.3.0</version> </dependency>
主要是通过工程类的定义
编写实现代码如下
public class CuratorLockTest { public static void main(String[] args) { // 创建分布式锁1 InterProcessMutex lock1 = new InterProcessMutex(getCuratorFramework(), "/locks"); // 创建分布式锁2 InterProcessMutex lock2 = new InterProcessMutex(getCuratorFramework(), "/locks"); new Thread(new Runnable() { @Override public void run() { try { lock1.acquire(); System.out.println("线程1 获取到锁"); lock1.acquire(); System.out.println("线程1 再次获取到锁"); Thread.sleep(5 * 1000); lock1.release(); System.out.println("线程1 释放锁"); lock1.release(); System.out.println("线程1 再次释放锁"); } catch (Exception e) { e.printStackTrace(); } } }).start(); new Thread(new Runnable() { @Override public void run() { try { lock2.acquire(); System.out.println("线程2 获取到锁"); lock2.acquire(); System.out.println("线程2 再次获取到锁"); Thread.sleep(5 * 1000); lock2.release(); System.out.println("线程2 释放锁"); lock2.release(); System.out.println("线程2 再次释放锁"); } catch (Exception e) { e.printStackTrace(); } } }).start(); } private static CuratorFramework getCuratorFramework() { ExponentialBackoffRetry policy = new ExponentialBackoffRetry(3000, 3); CuratorFramework client = CuratorFrameworkFactory.builder().connectString("hadoop102:2181,hadoop103:2181,hadoop104:2181") .connectionTimeoutMs(2000) .sessionTimeoutMs(2000) .retryPolicy(policy).build(); // 启动客户端 client.start(); System.out.println("zookeeper 启动成功"); return client; } }
总结企业面试
企业中常考的面试有选举机制、集群安装以及常用命令
选举机制 半数机制,超过半数的投票通过,即通过。 (1)第一次启动选举规则: 投票过半数时,服务器 id 大的胜出 (2)第二次启动选举规则: ①EPOCH 大的直接胜出 ②EPOCH 相同,事务 id 大的胜出 ③事务 id 相同,服务器 id 大的胜出
集群安装
-
安装奇数台
-
服务器台数多:好处,提高可靠性;坏处:提高通信延时
常用命令 ls、get、create、delete
算法基础
以下的算法基础主要研究数据是如何保持一致性的 也就是多台服务器的决定问题 比如著名的拜占庭将军问题
Paxos 算法
一种基于消息传递且具有高度容错特性的一致性算法
Paxos算法解决的问题:就是如何快速正确的在一个分布式系统中对某个数据值达成一致,并且保证不论发生任何异常,都不会破坏整个系统的一致性 有唯一的请求id 不接受比其更小的id发话
情况1: 情况2:A5的覆盖,同时A5做了老大
情况3:
以上情况是因为多个 Proposers 相互争夺 Acceptor,造成迟迟无法达成一致的情况。针对这种情况。一种改进的 Paxos 算法被提出:从系统中选出一个节点作为 Leader,只有 Leader 能够发起提案。这样,一次 Paxos 流程中只有一个Proposer,不会出现活锁的情况,此时只会出现例子中第一种情况
ZAB协议
只有一个服务器提交,没有服务器抢 主要的消息广播如下
-
准备发送,确认收到发送
-
在发送事务,确认收到事务过半之后
-
全部发送消息
但如果宕机 假设两种服务器异常情况: (1)假设一个事务在Leader提出之后,Leader挂了。 (2)一个事务在Leader上提交了,并且过半的Follower都响应Ack了,但是Leader在Commit消息发出之前挂了。
Zab协议崩溃恢复要求满足以下两个要求: (1)确保已经被Leader提交的提案Proposal,必须最终被所有的Follower服务器提交。 (已经产生的提案,Follower必须执行) (2)确保丢弃已经被Leader提出的,但是没有被提交的Proposal。(丢弃胎死腹中的提案)
之后开始新的leader的选举 Leader选举:根据上述要求,Zab协议需要保证选举出来的Leader需要满足以下条件: (1)新选举出来的Leader不能包含未提交的Proposal。即新Leader必须都是已经提交了Proposal的Follower服务器节点 (2)新选举的Leader节点中含有最大的zxid。这样做的好处是可以避免Leader服务器检查Proposal的提交和丢弃工作。
CAP理论
分布式系统不能同时满足以下三种: 一致性(多个副本之间是否能够保持数据一致的特性) 可用性(系统提供的服务必须一直处于可用的状态) 分区容错性(分布式系统在遇到任何网络分区故障的时候,仍然需要能够保证对外提供满足一致性和可用性的服务)
这三个基本需求,最多只能同时满足其中的两项,因为P是必须的,因此往往选择就在CP或者AP中
ZooKeeper保证的是一致性和分区容错性