Zookeeper是一个开源的分布式的，为分布式框架提供协调服务的 Apache 项目。
Zookeeper = 文件系统 + 通知机制
Zookeeper是一个基于观察者模式设计的分布式服务管理框架：它负者存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就通知对应的观察者。
特点：
1）Zookeeper：一个领导者（Leader），多个跟随者（Follower）组成的集群。
2）集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。所以Zookeeper适合安装奇数台服务器。
3）全局数据一致：每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据都是一致的。
4）更新请求顺序执行，来自同一个Client的更新请求按其发送顺序依次执行。
5）数据更新原子性，一次数据更新要么成功，要么失败。
6）实时性，在一定时间范围内，Client能读到最新数据。
数据结构：
ZooKeeper 数据模型的结构与 Unix 文件系统很类似，整体上可以看作是一棵树，每个节点称做一个 ZNode。每一个 ZNode 默认能够存储 1MB 的数据，每个 ZNode 都可以通过其路径唯一标识。
应用场景：
统一命名服务：
统一配置管理：可将配置信息写入Zookeeper上的一个Znode，各个客户端监听这个Znode，一旦Znode中的数据被修改，Zookeeper将通知各个客户端。
统一集群管理：
服务注册与发现：
软负载均衡：在Zookeeper中记录每台服务器的访问数，让访问数最少的去处理最新的客户端请求。
生产集群多少Zookeeper合适
安装奇数台：
10 台服务器：3 台 zk；
20 台服务器：5 台 zk；
100 台服务器：11 台 zk；
200 台服务器：11 台 zk
服务器台数多：好处，提高可靠性；坏处：提高通信延时
下载地址：
安装JDK
（代码略）
解压改名：
[atguigu@hadoop102 software]$ tar -zxvf apache-zookeeper-3.5.7-bin.tar.gz -C /opt/module/
[atguigu@hadoop102 software]$ cd /opt/module/
[atguigu@hadoop102 module]$ mv apache-zookeeper-3.5.7-bin/ zookeeper-3.5.7
配置zoo.cfg文件：
[atguigu@hadoop102 module]$ cd zookeeper-3.5.7/conf/
[atguigu@hadoop102 conf]$ mv zoo_sample.cfg zoo.cfg
[atguigu@hadoop102 conf]$ vim zoo.cfg
修改数据存储路径配置：
dataDir=/opt/module/zookeeper-3.5.7/zkData
创建zkData文件夹：
[atguigu@hadoop102 conf]$ cd /opt/module/zookeeper-3.5.7
[atguigu@hadoop102 zookeeper-3.5.7]$ mkdir zkData
启动 Zookeeper：
[atguigu@hadoop102 zookeeper-3.5.7]$ bin/zkServer.sh start
查看进程是否启动：
[atguigu@hadoop102 zookeeper-3.5.7]$ jps
4020 Jps
4001 QuorumPeerMain
[wanghaha@hadoop102 zookeeper-3.5.7]$ jps -l
22899 sun.tools.jps.Jps
21934 org.apache.zookeeper.server.quorum.QuorumPeerMain
查看状态：
[atguigu@hadoop102 zookeeper-3.5.7]$ bin/zkServer.sh status
ZooKeeper JMX enabled by default
Using config: /opt/module/zookeeper-3.5.7/bin/../conf/zoo.cfg
Mode: standalone
启动客户端：
[atguigu@hadoop102 zookeeper-3.5.7]$ bin/zkCli.sh
退出客户端：
[zk: localhost:2181(CONNECTED) 0] quit
停止 Zookeeper：
[atguigu@hadoop102 zookeeper-3.5.7]$ bin/zkServer.sh stop
-
- zoo.cfg）
- tickTime = 2000：通信心跳时间，Zookeeper服务器与客户端心跳时间，单位毫秒
- initLimit = 10：LF初始通信时限：Leader和Follower初始连接时能容忍的最多心跳数，超过指定心跳数则通讯失败
- syncLimit = 5：LF同步通信时限：Leader和Follower之间通信时间如果超过指定心跳，Leader认为Follwer死掉，从服务器列表中删除Follwer。
- dataDir：保存Zookeeper中的数据。注意：默认的tmp目录，容易被Linux系统定期删除，所以一般不用默认的tmp目录。
- clientPort = 2181：客户端连接端口，通常不做修改。
集群规划
| hadoop102 | hadoop103 | hadoop104 |
安装JDK
（代码略）
解压改名
[atguigu@hadoop102 software]$ tar -zxvf apache-zookeeper-3.5.7-bin.tar.gz -C /opt/module/
[atguigu@hadoop102 software]$ cd /opt/module/
[atguigu@hadoop102 module]$ mv apache-zookeeper-3.5.7-bin/ zookeeper-3.5.7
配置服务器编号
[atguigu@hadoop102 zookeeper-3.5.7]$ mkdir zkData
[atguigu@hadoop102 zookeeper-3.5.7]$ cd zkData
[atguigu@hadoop102 zkData]$ echo "2" > myid
配置zoo.cfg文件
[atguigu@hadoop102 module]$ cd /opt/module/zookeeper-3.5.7/conf
[atguigu@hadoop102 conf]$ mv zoo_sample.cfg zoo.cfg
[atguigu@hadoop102 conf]$ vim zoo.cfg
修改数据存储路径配置：
dataDir=/opt/module/zookeeper-3.5.7/zkData
增加集群服务器配置（格式：server.服务器编号=服务器地址:主从通信端口:重新选举通信端口）：
#######################cluster##########################
server.2=hadoop102:2888:3888
server.3=hadoop103:2888:3888
server.4=hadoop104:2888:3888
分发Zookeeper
[atguigu@hadoop102 conf]$ cd ../../
[atguigu@hadoop102 module ]$ xsync zookeeper-3.5.7
分别在hadoop103、hadoop104上修改myid文件中内容为3、4
（代码略）
分别启动Zookeeper
[atguigu@hadoop102 zookeeper-3.5.7]$ bin/zkServer.sh start
[atguigu@hadoop103 zookeeper-3.5.7]$ bin/zkServer.sh start
[atguigu@hadoop104 zookeeper-3.5.7]$ bin/zkServer.sh start
查看状态
[atguigu@hadoop102 zookeeper-3.5.7]# bin/zkServer.sh status
JMX enabled by default
Using config: /opt/module/zookeeper-3.5.7/bin/../conf/zoo.cfg
Mode: follower
[atguigu@hadoop103 zookeeper-3.5.7]# bin/zkServer.sh status
JMX enabled by default
Using config: /opt/module/zookeeper-3.5.7/bin/../conf/zoo.cfg
Mode: leader
[atguigu@hadoop104 zookeeper-3.4.5]# bin/zkServer.sh status
JMX enabled by default
Using config: /opt/module/zookeeper-3.5.7/bin/../conf/zoo.cfg
Mode: follower
集群启停脚本
[atguigu@hadoop102 kafka]$ cd /home/atguigu/bin
[atguigu@hadoop102 bin]$ vim 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 |
添加执行权限
[atguigu@hadoop102 bin]$ chmod u+x zk.sh
启动集群命令
[atguigu@hadoop102 ~]$ zk.sh start
停止集群命令
[atguigu@hadoop102 ~]$ zk.sh stop
启动客户端
[atguigu@hadoop102 ~]$ cd /opt/module/zookeeper-3.5.7
[atguigu@hadoop102 zookeeper-3.5.7]$ bin/zkCli.sh -server hadoop102:2181
常用命令：
| 命令 | 含义 | 示例 |
| help | 显示所有操作命令 | [zk: hadoop102:2181(CONNECTED) 1] help |
| ls path -w -s | 查看当前znode的子节点 监听子节点变化 附加次级信息 | [zk: hadoop102:2181(CONNECTED) 0] ls / [zookeeper] [zk: hadoop102:2181(CONNECTED) 5] ls -s / [zookeeper] cZxid = 0x0 # znode被创建的事务zxid ctime = Thu Jan 01 08:00:00 CST 1970 # znode被创建的毫秒数 mZxid = 0x0 # znode最后更新的事务 zxid mtime = Thu Jan 01 08:00:00 CST 1970 # znode 最后修改的毫秒数 pZxid = 0x0 # znode最后更新的子节点 zxid cversion = -1 # znode子节点修改次数 dataVersion = 0 # znode数据修改次数 aclVersion = 0 # znode访问控制列表修改次数 ephemeralOwner = 0x0 # 临时znode拥有者的session id/非临时znode此值为0 dataLength = 0 # znode的数据长度 numChildren = 1 # znode子节点数量 |
| create -s -e | 普通创建 含有序列 临时（会话断开时消失） | [zk: localhost:2181(CONNECTED) 3] create /sanguo "diaochan" Created /sanguo [zk: localhost:2181(CONNECTED) 4] create /sanguo/shuguo "liubei" Created /sanguo/shuguo [zk: localhost:2181(CONNECTED) 1] create /sanguo/weiguo "caocao" Created /sanguo/weiguo # 创建带序号的节点（若先无同辈节点，则序号从0始。若先有同辈节点，则序号从已有数始）： [zk: localhost:2181(CONNECTED) 2] create -s /sanguo/weiguo/zhangliao "zhangliao" Created /sanguo/weiguo/zhangliao0000000000 [zk: localhost:2181(CONNECTED) 3] create -s /sanguo/weiguo/zhangliao "zhangliao" Created /sanguo/weiguo/zhangliao0000000001 [zk: localhost:2181(CONNECTED) 4] create -s /sanguo/weiguo/xuchu "xuchu" Created /sanguo/weiguo/xuchu0000000002 |
| get path -w -s | 获取节点值 监听节点内容变化（watch） 附加次级信息 | [zk: localhost:2181(CONNECTED) 5] get -s /sanguo diaochan cZxid = 0x100000003 ...... |
| set | 设置节点值 | [zk: localhost:2181(CONNECTED) 6] set /sanguo/weiguo "simayi" |
| stat | 查看节点状态 | [zk: localhost:2181(CONNECTED) 17] stat /sanguo cZxid = 0x100000003 ...... |
| delete | 删除节点 | [zk: localhost:2181(CONNECTED) 4] delete /sanguo/jin |
| deleteall | 递归删除节点 | [zk: localhost:2181(CONNECTED) 15] deleteall /sanguo/shuguo |
| quit | 退出客户端 |
zxid：每次修改 ZooKeeper 状态都会产生一个zxid（唯一、递增）
客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、节点删除、子目录节点增加删除）时，ZooKeeper 会通知客户端。监听机制保证 ZooKeeper 保存的任何的数据的任何改变都能快速的响应到监听了该节点的应用程序。
监听器原理详解
- 首先要有一个main()线程。
- 在main线程中创建Zookeeper客户端，这时候就会创建两个线程：一个负责网络连接通信（connect），一个负责监听（listener）。
- 客户端通过connect线程将注册的监听事件发送给Zookeeper服务端。
- 服务端将监听事件添加到监听器列表中。
- 服务端监听到有数据或路径变化，就会将这个消息发送给客户端listener线程。
- 客户端listener线程内部调用了process()方法。
节点的值变化监听：get -w path
在 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上不会再收到监听。因为注册一次，只能监听一次。想再次监听，需要再次注册。
节点的子节点变化监听（路径变化）:ls -w path
在 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
注意：节点的路径变化，也是注册一次，生效一次。想多次生效，就需要多次注册。
-
- API 操作
创建maven工程zookeeper
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 |
com.atguigu.zk.ZkClient
| //注意逗号左右不能有空格 private static String connectString ="hadoop102:2181,hadoop103:2181,hadoop104:2181"; private static int sessionTimeout = 2000; private ZooKeeper zkClient = null; /** * 创建客户端 */ @Before public void init() throws Exception { zkClient = new ZooKeeper(connectString, sessionTimeout, new Watcher() { @Override public void process(WatchedEvent watchedEvent) { // 收到事件通知后的回调函数（用户的业务逻辑） System.out.println(watchedEvent.getType() + "--" + watchedEvent.getPath()); // 再次注册监听（注册一次，只能监听一次，所以每次监听完再注册一次） try { //true：使用 new ZooKeeper 时传入的默认监听器 List<String> children = zkClient.getChildren("/", true); for (String child : children) { System.out.println(child); } } catch (Exception e) { //TODO: logErr } } }); } /** * 创建子节点 */ @Test public void create() throws Exception { // 参数列表：节点路径；节点数据；节点权限；节点类型 String nodeCreated = zkClient.create("/atguigu", "shuaige".getBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT); } /** * 获取子节点并监听子节点变化 */ @Test public void getChlidren() throws InterruptedException, KeeperException { //true：使用 new ZooKeeper 时传入的默认监听器 List<String> children = zkClient.getChildren("/", true); for (String child : children) { System.out.println(child); } // 延时，监听器还在循环监听 Thread.sleep(Long.MAX_VALUE); } /** * 判断节点是否存在 */ @Test public void exist() throws InterruptedException, KeeperException { Stat stat = zkClient.exists("/atguigu", false); System.out.println(stat==null?"not exist":"exist"); } |
-
- 案例
思路
- 服务提供者启动时去Zookeeper注册信息（创建临时节点create -e）
- 服务消费者启动时去Zookeeper获取在线的服务提供者列表，并且注册监听（ls -w）
- 某个服务提供者下线（临时节点消失）
- Zookeeper监听到临时节点消失，通知注册了监听的服务消费者
- 服务消费者监听回调函数process()中重新去Zookeeper获取在线的服务提供者列表，并且注册监听（ls -w）
实现
在Zookeeper集群上创建/servers 节点
[zk: localhost:2181(CONNECTED) 10] create /servers "servers"
Created /servers
服务提供者
| package com.wanghaha.case1; import org.apache.zookeeper.*; import java.io.IOException; public class DistributeServer { private String connectString = "hadoop102:2181,hadoop103:2181,hadoop104:2181"; private int sessionTimeout = 2000; private ZooKeeper zooKeeper; public static void main(String[] args) throws IOException, InterruptedException, KeeperException { 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 InterruptedException, KeeperException { // 路径， 主机名称， 安全， 创建的节点类型为 临时的，带序号的 zooKeeper.create("/servers/"+hostname,hostname.getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL); System.out.println(hostname + " is online"); } private void getConnect() throws IOException { zooKeeper = new ZooKeeper(connectString, sessionTimeout, new Watcher() { @Override public void process(WatchedEvent watchedEvent) { } }); } } |
服务消费者
| package com.wanghaha.case1; import org.apache.zookeeper.KeeperException; import org.apache.zookeeper.WatchedEvent; import org.apache.zookeeper.Watcher; import org.apache.zookeeper.ZooKeeper; import java.io.IOException; import java.util.ArrayList; import java.util.List; public class DistributeClient { private String connectString = "hadoop102:2181,hadoop103:2181,hadoop104:2181"; private int sessiongTimeout = 2000; private ZooKeeper zk; public static void main(String[] args) throws IOException, InterruptedException, KeeperException { 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 InterruptedException, KeeperException { // true的话走的是getConnect中的监听 // new的话走的是自己创建的监听 // 1 获取服务器子节点信息，并且对父节点进行监听 List<String> children = zk.getChildren("/servers", true); // 2 存储服务器信息列表 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, sessiongTimeout, new Watcher() { @Override public void process(WatchedEvent watchedEvent) { // 监听只触发一次， 再调用 再次启动监听 try { getServerList(); } catch (InterruptedException e) { e.printStackTrace(); } catch (KeeperException e) { e.printStackTrace(); } } }); } } |
测试
- 启动 DistributeClient
- 启动 DistributeServer：
- 先注释掉main方法体，空跑一下main方法
- 点击 Edit Configurations…
- 在弹出的窗口中，Program arguments处输入想启动的主机名，例如，hadoop102
- 取消注释main方法体，运行main方法。
- 观察 DistributeServer 控制台，提示 hadoop102 is online
- 观察 DistributeClient 控制台，提示 [hadoop102] 已经上线
思路
- 接收到请求后，在/locks节点下创建一个临时顺序节点
- 判断自己是否最小节点：是，获取到锁；否，监听前一个节点的删除事件
- 获取到锁，处理完业务后，删除节点释放锁，然后下面的节点将收到通知，重复第二步判断
实现
DistributedLock
| package com.wanghaha.case2; import org.apache.zookeeper.*; import org.apache.zookeeper.data.Stat; import java.io.IOException; import java.util.Collections; import java.util.List; import java.util.concurrent.CountDownLatch; 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; //ZooKeeper 节点等待 private String currentMode; // 当前 client 创建的子节点 // 和 zk 服务建立连接，并创建根节点 public DistributedLock() throws IOException, InterruptedException, KeeperException { // 获取连接 zk = new ZooKeeper(connectString, sessionTimeout, new Watcher() { @Override public void process(WatchedEvent watchedEvent) { // 连接建立时, 打开 latch, 唤醒 wait 在该 latch 上的线程 // connectLatch 如果连接zk上之后可以释放 if(watchedEvent.getState() == Event.KeeperState.SyncConnected){ connectLatch.countDown(); } // waitPath 需要释放 // 如果当前操作类型，为Event.EventType.NodeDeleted， 并且操作节点为 waitPath 释放 if(watchedEvent.getType() == Event.EventType.NodeDeleted && watchedEvent.getPath().equals(waitPath)){ waitLatch.countDown(); } } }); try { // 等待zk正常连接后，往下走程序 connectLatch.await(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new RuntimeException(e); } // 判断根节点/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 zkkLock(){ // 创建对应的临时的带序号的节点 try { //在根节点下创建临时顺序节点，返回值为创建的节点路径 currentMode = zk.create("/locks/" + "seq-", null, ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL); // 判断创建的节点是否是最小的节点，如果是获取到锁；如果不是监听他序号前一个节点 List<String> children = zk.getChildren("/locks", false); // 如果chlidren只用一个值那就直接获取锁； 如果有多个节点，需要判断，谁最小 if(children.size() == 1){ return; }else{ // 对根节点下的所有临时顺序节点进行从小到大排序 Collections.sort(children); // 获取节点名称 String thisNode = currentMode.substring("/locks/".length()); // seq-000000 // 通过seq-000000获取到在集合当中的位置 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, null); // 等待监听 waitLatch.await(); return; } } } catch (KeeperException e) { e.printStackTrace(); } catch (InterruptedException e) { e.printStackTrace(); } } // 对zk解锁 public void unZkLock(){ // 删除节点 try { zk.delete(currentMode,-1); } catch (InterruptedException e) { e.printStackTrace(); } catch (KeeperException e) { e.printStackTrace(); } } } |
测试
| package com.wanghaha.case2; import org.apache.zookeeper.KeeperException; import java.io.IOException; public class DistributedLockTest { public static void main(String[] args) throws IOException, InterruptedException, KeeperException { final DistributedLock lock1 = new DistributedLock(); final DistributedLock lock2 = new DistributedLock(); new Thread(new Runnable() { @Override public void run() { try { lock1.zkkLock();// 加锁，创建节点 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.zkkLock();// 加锁，创建节点 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）不支持多节点删除和创建。需要自己去递归
Curator 是一个专门解决分布式锁的框架，解决了原生 JavaAPI 开发分布式遇到的问题。
详情请查看官方文档：Apache Curator
Curator 案例实操：
1）添加依赖：
|
2）代码实现：
|
3）观察控制台变化：
|
Paxos算法是一种基于消息传递且具有高度容错特性的一致性算法。
在一个Paxos系统中，首先将所有节点划分成提议者（proposer），接收者（acceptor），学习者（learner）。（每一个节点都可以身兼数职）。
一个完整的Paxos算法流程分为三个阶段五个步骤：
（1）Prepare: Proposer生成全局唯一且递增的Proposal ID，向所有Acceptor发送Propose请求，这里无需携带提案内容，只携带Proposal ID。
（2）Promise: Acceptor收到Propose请求后，做出“两个承诺，一个应答”：
不再接受Proposal ID小于等于（注意：这里是<= ）当前请求的Propose请求。
不再接受Proposal ID小于（注意：这里是< ）当前请求的Accept请求。
不违背以前做出的承诺下，回复已经Accept过的提案中Proposal ID最大的那个提案的Value和Proposal ID，没有则返回空值。
（3）Propose: Proposer收到多数Acceptor的Promise应答后，从应答中选择Proposal ID最大的提案的Value，作为本次要发起的提案。如果所有应答的提案Value均为空值，则可以自己随意决定提案Value。然后携带当前Proposal ID，向所有Acceptor发送Propose请求。
（4）Accept: Acceptor收到Propose请求后，在不违背自己之前做出的承诺下，接受并持久化当前Proposal ID和提案Value。
（5）Learn: Proposer收到多数Acceptor的Accept后，决议形成，将形成的决议发送给所有Learner。
下面我们针对上述描述做三种情况的推演举例：为了简化流程，我们这里不设置 Learner。
A1,A2,A3,A4,A5五位议员就税率问题进行决议
情况一：
1.A1发起Proposal的Propose（未告知决议的内容），等待承诺
2.A2-A5回应promise
3.A1在收到两份回复时就会发起税率10%的proposal
4.A2-A5回应accept
5.通过proposal，税率10%
情况二：
A1提出提案的同时，A5决定将税率定为20%
1.A1，A5同时发起Proposal的Propose（序号分别为1，2）
2.A2承诺A1，A4承诺A5，A3成为关键
3.A3先收到A1消息，承诺A1
4.A1发起proposal（1，10%），A2，A3接受
5.之后A3又收到A5消息，回复A1：（1，10%），并承诺A5
6.A5发起proposal（2，20%），A3，A4接受，之后A1，A5同时广播决议，由于A5的proposal ID大，A2，A3更新承诺
情况三：
A3先收到A1的消息，承诺A1，之后立刻收到A5的消息，承诺A5
A1发起Proposal（1，10%），无足够响应，A1重新propose（序号为3），A3再次承诺A1
A5发起Proposal（2，20%），无足够响应，A5重新propose（序号为4），A3再次承诺A5
以此往复
造成这种情况的原因是系统中有一个以上的 Proposer，多个 Proposers 相互争夺 Acceptor，造成迟迟无法达成一致的情况。针对这种情况，一种改进的 Paxos 算法被提出：从系统中选出一个节点作为 Leader，只有 Leader 能够发起提案。这样，一次 Paxos 流程中只有一个Proposer，不会出现活锁的情况，此时只会出现例子中第一种情况。
Zab 借鉴了 Paxos 算法，是特别为 Zookeeper 设计的支持崩溃恢复的原子广播协议。基于该协议，Zookeeper 设计为只有一台客户端（Leader）负责处理外部的写事务请求，然后Leader 客户端将数据同步到其他 Follower 节点。即 Zookeeper 只有一个 Leader 可以发起提案。
Zab 协议包括两种基本的模式：消息广播、崩溃恢复。
消息广播
ZAB协议针对事务请求的处理过程类似于一个两阶段提交过程:(1）广播事务阶段(2）广播提交操作
过程
(1）客户端发起一个写操作请求。
(2)Leader将请求转化为事务Proposal提案，同时为每个Proposal分配一个全局的ID，即zxid。
(3)Leader为每个Follower分配一个单独的队列，然后将需要广播的 Proposal依次放到队列中去，并且根据FIFO策略进行消息发送。
(4)Follower接收到Proposal后，会首先将其以事务日志的方式写入本地磁盘中，写入成功后向Leader反馈一个Ack响应消息。
(5)Leader接收到超过半数以上Follower的Ack响应消息后，即认为消息发送成功，可以发送commit消息。
(6)Leader向所有Follower广播commit消息，同时自身也会完成事务提交。Follower接收到commit消息后，会将上一条事务提交。
(7) Zookeeper采用Zab协议的核心，就是只要有一台服务器提交了Proposal，就要确保所有的服务器最终都能正确提交Proposal。
崩溃恢复
一旦Leader崩溃或由于网络原因导致Leader失去了与过半Follower的联系，那么就会进入崩溃恢复模式。
假设两种服务器异常情况
(1）Leader在发起事务Proposal后宕机，Follower都没有Proposal。
(2）Leader在收到半数ACK后，发起commit前宕机，Follower都没有commit
Zab协议崩溃恢复要求满足以下两个要求:
(1）确保已经被Leader提交的提案Proposal，必须最终被所有的Follower服务器提交。(已经产生的提案，Follower必须执行)
(2）确保丢弃已经被Leader提出的，但是没有被提交的Proposal。（丢弃胎死腹中的提案）
崩溃恢复主要包括两部分：Leader选举和数据恢复
Leader选举
选举条件:
(1）新选举出来的Leader不能包含未提交的Proposal。即新Leader必须都是已经提交了Proposal的Follower服务器节点。
(2）新选举的Leader节点中含有最大的zxid。这样做的好处是可以避免Leader检查Proposal的提交和丢弃工作。
选举过程：
半数机制，超过半数的投票通过。
（1）第一次启动选举规则：
投票过半数时，服务器id大的胜出
（2）非第一次启动选举规则：
①EPOCH大的直接胜出
②EPOCH相同，事务id大的胜出
③事务id相同，服务器id大的胜出
注：
EPOCH：zxid的前32位，指leader任期
事务id：zxid的后32位，指数据更新次数
服务器id：即myid
数据恢复
(1）完成Leader选举后，在正式开始工作之前（接收事务请求，然后提出新的Proposal), Leader服务器会首先确认事务日志中的所有的Proposal是否已经被集群中过半的服务器Commit。
(2)Leader服务器需要确保所有的Follower服务器能够接收到每一条事务的Proposal，并且能将所有已经提交的事务Proposal应用到内存数据中。等到Follower将所有尚未同步的事务Proposal都从Leader服务器上同步过，并且应用到内存数据中以后，Leader才会把该Follower加入到真正可用的Follower列表中。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
