高清思维导图已同步Git：https://github.com/SoWhat1412/xmindfile
引言
很多中间件，比如Kafka、Hadoop、HBase，都用到了 Zookeeper，于是很多人就会去了解这个 Zookeeper 到底是什么，为什么它在分布式系统里有着如此无可替代的地位。
其实学任何一项技术，首先都要弄明白，为什么需要这项技术。
为什么需要 Zookeeper
正经点来回答，就是我们需要一个
用起来像单机但是又比单机更可靠的 高可用的东西。
下面开始不正经的回答。
一个团队里面，需要一个leader，leader是干嘛用的？管理什么的咱不说，就说如果外面的人，想问关于这个团队的一切事情，首先就会去找这个leader，因为他知道的最多，而且他的回答最靠谱。
比如产品经理小麦过来要人，作为leader，老吕发现sowhat最近没有项目安排，于是把sowhat安排给了小麦的项目；
过了一会，另一个产品阿城也过来要人，老吕发现刚刚把sowhat安排走了，已经没人，于是就跟小西说，人都被你们产品要走了，你们产品自己去协调去。
如果老吕这时候忘了sowhat已经被安排走了，把sowhat也分配给小西，那到时两个产品就要打架了。这就是leader在团队里的协调作用。
同样的，在分布式系统中，也需要这样的协调者，来回答系统下各个节点的提问。
比如我们搭建了一个数据库集群，里面有一个Master，多个Slave，Master负责写，Slave只读，我们需要一个系统，来告诉客户端，哪个是Master。
有人说，很简单，我们把这个信息写到一个Java服务器的内存就好了，用一个map，key:master，value:master机器对应的ip
但是别忘了，这是个单机，一旦这个机器挂了，就完蛋了，客户端将无法知道到底哪个是Master。于是开始进行拓展，拓展成三台服务器的集群。
问题:
这下问题来了，如果我在其中一台机器修改了Master的ip，数据还没同步到其他两台，这时候客户端过来查询，如果查询走的是另外两台还没有同步到的机器，就会拿到旧的数据，往已经不是master的机器写数据。
所以我们需要这个存储master信息的服务器集群，做到当信息还没同步完成时，不对外提供服务，阻塞住查询请求，等待信息同步完成，再给查询请求返回信息。这样一来，请求就会变慢，变慢的时间取决于什么时候这个集群认为数据同步完成了。
假设这个数据同步时间无限短，比如是1微妙，可以忽略不计，那么其实这个分布式系统，就和我们之前单机的系统一样，既可以保证数据的一致，又让外界感知不到请求阻塞，同时，又不会有SPOF（Single Point of Failure）的风险，即不会因为一台机器的宕机，导致整个系统不可用。
这样的系统，就叫分布式协调系统。谁能把这个数据同步的时间压缩的更短，谁的请求响应就更快，谁就更出色，Zookeeper就是其中的佼佼者。
它用起来像单机一样，能够提供数据强一致性，但是其实背后是多台机器构成的集群，不会有SPOF。
其实就是CAP理论中，满足CP，不满足A的那类分布式系统。
PS：
CAP原则又称CAP定理，指的是在一个分布式系统中，
一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
如果把各个节点比作各种小动物，那协调者，就是动物园管理员，这也就是Zookeeper名称的由来了，从名字就可以看出来它的雄心勃勃。
讲完了上面这些，现在再来看官网这句话，就很能理解了：
ZooKeeper: A Distributed Coordination Service for Distributed Applications
What is ZooKeeper?
ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.
zk入门
概述
Zookeeper是一个开源的分布式的，为分布式应用提供协调服务的Apache项目
Zookeeper = 文件系统 + 通知机制
工作机制如下：
特点(重点)
- Zookeeper：一个领导者（Leader），多个跟随者（Follower）组成的集群。
- 集群中只要有
半数以上节点存活，Zookeeper集群就能正常服务。 - 全局数据
一致：每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据都是一致的。 - 更新请求顺序进行，来自同一个Client的更新请求按其发送顺序依次执行。
- 数据更新
原子性，一次数据更新要么成功，要么失败。 实时性，在一定时间范围内，Client能读到最新数据。
数据结构
ZooKeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。每一个ZNode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识。
场景
提供的服务包括：统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等。
- 统一命名服务
- 统一配置管理
- 统一集群管理
- 服务器节点动态上下线
- 软负载均衡
zk 安装
本地模式安装部署
- 安装前准备
（1）安装Jdk
（2）拷贝Zookeeper安装包到Linux系统下
（3）解压到指定目录
[atguigu@hadoop102 software]$ tar -zxvf zookeeper-3.4.10.tar.gz -C /opt/module/
- 配置修改
（1）将/opt/module/zookeeper-3.4.10/conf这个路径下的zoo_sample.cfg修改为zoo.cfg；
（2）打开zoo.cfg文件，修改dataDir路径(记得该目录先手动创建下)：
dataDir=/opt/module/zookeeper-3.4.10/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.4.10/bin/…/conf/zoo.cfg
Mode: standalone
（4）启动客户端： bin/zkCli.sh
（5）退出客户端：quit
（6）停止Zookeeper : bin/zkServer.sh stop
配置参数解读
Zookeeper中的配置文件zoo.cfg中参数含义解读如下：
1．tickTime =2000：通信心跳数，Zookeeper服务器与客户端心跳时间，单位毫秒。Zookeeper使用的基本时间，服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个tickTime时间就会发送一个心跳，时间单位为毫秒。它用于心跳机制，并且设置最小的session超时时间为两倍心跳时间。(session的最小超时时间是2*tickTime)
2．initLimit =10：LF初始通信时限
集群中的Follower跟随者服务器与Leader领导者服务器之间初始连接时能容忍的最多心跳数（tickTime的数量），用它来限定集群中的Zookeeper服务器连接到Leader的时限。
3．syncLimit =5：LF同步通信时限
集群中Leader与Follower之间的最大响应时间单位，假如响应超过syncLimit * tickTime，Leader认为Follwer死掉，从服务器列表中删除Follwer。
4．dataDir：数据文件目录+数据持久化路径
主要用于保存Zookeeper中的数据。
5．clientPort =2181：客户端连接端口
监听客户端连接的端口。
zk 原理
1 选举机制（面试重点）
1）半数机制：集群中半数以上机器存活，集群可用。所以Zookeeper适合安装奇数台服务器。
2）Zookeeper虽然在配置文件中并没有指定Master和Slave。但是，Zookeeper工作时，是有一个节点为Leader，其他则为Follower，Leader是通过内部的选举机制临时产生的。
3）以一个简单的例子来说明整个选举的过程。
假设有五台服务器组成的Zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样的。假设这些服务器依序启动，来看看会发生什么，如下图所示。
因为一共5台服务器，只有超过半数以上，即最少启动3台服务器，集群才能正常工作。
（1）服务器1启动，发起一次选举。
服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成；
服务器1状态保持为LOOKING；
（2）服务器2启动，再发起一次选举。
服务器1和2分别投自己一票，此时服务器1发现服务器2的id比自己大，更改选票投给服务器2；
此时服务器1票数0票，服务器2票数2票，不够半数以上（3票），选举无法完成；
服务器1，2状态保持LOOKING；
- 服务器3启动，发起一次选举。
与上面过程一样，服务器1和2先投自己一票，然后因为服务器3id最大，两者更改选票投给为服务器3；
此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数（3票），服务器3当选Leader。
服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING；
- 服务器4启动，发起一次选举。
此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。
此时服务器4服从多数，更改选票信息为服务器3；
服务器4并更改状态为FOLLOWING；
- 服务器5启动，同4一样投票给3，此时服务器3一共5票，服务器5为0票；
服务器5并更改状态为FOLLOWING；
- 最终
Leader是服务器3，状态为LEADING；
其余服务器是Follower，状态为FOLLOWING。
节点类型
Stat 结构
- czxid-创建节点的事务zxid
每次修改ZooKeeper状态都会收到一个zxid形式的时间戳，也就是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子节点数量
监听器原理
监听类型：
- 监听节点数据的变化 get path [watch]
- 监听子节点增减的变化 ls path [watch]
监听流程：
1）首先要有一个main()线程
2）在main线程中创建Zookeeper客户端，这时就会创建两个线程，一个负责网络连接通信（connet），一个负责监听（listener）。
3）通过connect线程将注册的监听事件发送给Zookeeper。
4）在Zookeeper的注册监听器列表中将注册的监听事件添加到列表中。
5）Zookeeper监听到有数据或路径变化，就会将这个消息发送给listener线程。
6）listener线程内部调用了process()方法。
写流程
ZAB 协议全称：Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）。Zookeeper 是一个为分布式应用提供高效且可靠的分布式协调服务。在解决分布式一致性方面，Zookeeper 并没有使用 Paxos ，而是采用了 ZAB 协议。
zk 实战(重点)
分布式安装部署
- 集群规划
在hadoop102、hadoop103和hadoop104三个节点上部署Zookeeper。
- 解压安装
解压Zookeeper安装包到/opt/module/目录下
[atguigu@hadoop102 software]$ tar -zxvf zookeeper-3.4.10.tar.gz -C /opt/module/
同步/opt/module/zookeeper-3.4.10目录内容到hadoop103、hadoop104
[atguigu@hadoop102 module]$ xsync zookeeper-3.4.10/
- 配置服务器编号
在/opt/module/zookeeper-3.4.10/这个目录下创建zkData
[atguigu@hadoop102 zookeeper-3.4.10]$ mkdir -p zkData
在/opt/module/zookeeper-3.4.10/zkData目录下创建一个myid的文件
[atguigu@hadoop102 zkData]$ touch myid
添加myid文件，注意一定要在linux里面创建，在notepad++里面很可能乱码
编辑myid文件
[atguigu@hadoop102 zkData]$ vi myid
在文件中添加与server对应的编 号：2
拷贝配置好的zookeeper到其他机器上
[atguigu@hadoop102 zkData]$ xsync myid
并分别在hadoop102、hadoop103上修改myid文件中内容为3、4
配置zoo.cfg文件
重命名
[atguigu@hadoop102 conf]$ mv /opt/module/zookeeper-3.4.10/conf/zoo_sample.cfg /opt/module/zookeeper-3.4.10/conf/zoo.cfg
添加 dataDir
[atguigu@hadoop102 conf]$ vim zoo.cfg
修改数据存储路径配置
dataDir=/opt/module/zookeeper-3.4.10/zkData
增加如下配置
#######################cluster##########################
server.2=hadoop102:2888:3888
server.3=hadoop103:2888:3888
server.4=hadoop104:2888:3888
同步zoo.cfg配置文件
[atguigu@hadoop102 conf]$ xsync zoo.cfg
配置参数解读
server.A=B:C:D。
A:是一个数字，表示这个是第几号服务器；
集群模式下配置一个文件myid，这个文件在dataDir目录下，这个文件里面有一个数据就是A的值，Zookeeper启动时读取此文件，拿到里面的数据与zoo.cfg里面的配置信息比较从而判断到底是哪个server。
B:是这个服务器的ip地址；
C:是这个服务器与集群中的Leader服务器交换信息的端口；
D:是万一集群中的Leader服务器挂了，需要一个端口来重新进行选举，选出一个新的Leader，而这个端口就是用来执行选举时服务器相互通信的端口。
集群操作
分别启动Zookeeper
[atguigu@hadoop102 zookeeper-3.4.10]$ bin/zkServer.sh start
[atguigu@hadoop103 zookeeper-3.4.10]$ bin/zkServer.sh start
[atguigu@hadoop104 zookeeper-3.4.10]$ bin/zkServer.sh start
查看状态
[atguigu@hadoop102 zookeeper-3.4.10]# bin/zkServer.sh status
JMX enabled by default
Using config: /opt/module/zookeeper-3.4.10/bin/…/conf/zoo.cfg
Mode:follower
[atguigu@hadoop103 zookeeper-3.4.10]# bin/zkServer.sh status
JMX enabled by default
Using config: /opt/module/zookeeper-3.4.10/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.4.10/bin/…/conf/zoo.cfg
Mode:follower
命令行指令
| 命令基本语法 | 功能描述 |
|---|---|
| help | 显示所有操作命令 |
| ls path [watch] | 显示所有操作命令 |
| ls path [watch] | 查看当前节点数据并能看到更新次数等数据 |
| create | 普通创建 -s 含有序列， -e 临时（重启或者超时消失） |
| get path [watch] | 获得节点的值 |
| set | 设置节点的具体值 |
| stat | 查看节点状态 |
| delete | 删除节点 |
| rmr | 递归删除节点 |
- 启动客户端
[atguigu@hadoop103 zookeeper-3.4.10]$ bin/zkCli.sh
- 显示所有操作命令
[zk: localhost:2181(CONNECTED) 1]
help
- 查看当前znode中所包含的内容
[zk: localhost:2181(CONNECTED) 0]
ls/
- 查看当前节点详细数据
[zk: localhost:2181(CONNECTED) 1]
ls2/
[zookeeper]
cZxid = 0x0
ctime = Thu Jan 01 08:00:00 CST 1970
mZxid = 0x0
mtime = Thu Jan 01 08:00:00 CST 1970
pZxid = 0x0
cversion = -1
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 0
numChildren = 1
- 分别创建2个普通节点
[zk: localhost:2181(CONNECTED) 3]
create/sanguo “jinlian”
Created /sanguo
[zk: localhost:2181(CONNECTED) 4]create/sanguo/shuguo “liubei”
Created /sanguo/shuguo
- 获得节点的值
[zk: localhost:2181(CONNECTED) 5]
get/sanguo
jinlian
cZxid = 0x100000003
ctime = Wed Aug 29 00:03:23 CST 2018
mZxid = 0x100000003
mtime = Wed Aug 29 00:03:23 CST 2018
pZxid = 0x100000004
cversion = 1
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 7
numChildren = 1
- 创建短暂节点
[zk: localhost:2181(CONNECTED) 7]
create-e/sanguo/wuguo “zhouyu”
Created /sanguo/wuguo
在当前客户端是能查看到的
[zk: localhost:2181(CONNECTED) 3] ls /sanguo
[wuguo, shuguo]
退出当前客户端然后再重启客户端
[zk: localhost:2181(CONNECTED) 12] quit
[atguigu@hadoop104 zookeeper-3.4.10]$ bin/zkCli.sh
再次查看根目录下短暂节点已经删除
[zk: localhost:2181(CONNECTED) 0] ls /sanguo
[shuguo]
- 创建带序号的节点
先创建一个普通的根节点/sanguo/weiguo
[zk: localhost:2181(CONNECTED) 1] create /sanguo/weiguo “caocao”
Created /sanguo/weiguo
创建带序号的节点
[zk: localhost:2181(CONNECTED) 2] create
-s/sanguo/weiguo/xiaoqiao “jinlian”
Created /sanguo/weiguo/xiaoqiao0000000000
[zk: localhost:2181(CONNECTED) 3] create-s/sanguo/weiguo/daqiao “jinlian”
Created /sanguo/weiguo/daqiao0000000001
[zk: localhost:2181(CONNECTED) 4] create-s/sanguo/weiguo/diaocan “jinlian”
Created /sanguo/weiguo/diaocan0000000002
如果原来没有序号节点，序号从0开始依次递增。如果原节点下已有2个节点，则再排序时从2开始，以此类推。
- 修改节点数据值
[zk: localhost:2181(CONNECTED) 6] set /sanguo/weiguo “simayi”
- 节点的值变化监听 get path watch
在hadoop104主机上注册监听/sanguo节点数据变化
[zk: localhost:2181(CONNECTED) 26] [zk: localhost:2181(CONNECTED) 8]
get /sanguo watch
在hadoop103主机上修改/sanguo节点的数据
[zk: localhost:2181(CONNECTED) 1]
set/sanguo “xisi”
观察hadoop104主机收到数据变化的监听
WATCHER::
WatchedEvent state:SyncConnected type:NodeDataChangedpath:/sanguo
- 节点的子节点变化监听（路径变化）ls path watch
在hadoop104主机上注册监听/sanguo节点的子节点变化
[zk: localhost:2181(CONNECTED) 1]
ls /sanguo watch
[aa0000000001, server101]
在hadoop103主机/sanguo节点上创建子节点
[zk: localhost:2181(CONNECTED) 2] create /sanguo/jin “simayi”
Created /sanguo/jin
观察hadoop104主机收到子节点变化的监听
WATCHER::
WatchedEvent state:SyncConnected type:NodeChildrenChangedpath:/sanguo
- 删除节点
[zk: localhost:2181(CONNECTED) 4]
delete/sanguo/jin
- 递归删除节点
[zk: localhost:2181(CONNECTED) 15]
rmr/sanguo/shuguo
- 查看节点状态
[zk: localhost:2181(CONNECTED) 17]
stat/sanguo
API 使用
- pom.xml
<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>
<!-- https://mvnrepository.com/artifact/org.apache.zookeeper/zookeeper -->
<dependency>
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
<version>3.4.10</version>
</dependency>
</dependencies>
- log4j.properties
需要在项目的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
创建ZooKeeper客户端、创建子节点、获取子节点并监听节点变化、判断Znode是否存在
import org.apache.zookeeper.*;
import org.apache.zookeeper.ZooDefs.Ids;
import org.apache.zookeeper.data.Stat;
import org.junit.Before;
import org.junit.Test;
import java.io.IOException;
import java.util.List;
public class TestZookeeper {
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 event) {
System.out.println("---------start----------");
List<String> children;
try {
children = zkClient.getChildren("/", true);
for (String child : children) {
System.out.println(child);
}
System.out.println("---------end----------");
} catch (KeeperException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
});
}
// 1 创建节点
@Test
public void createNode() throws KeeperException, InterruptedException {
String path = zkClient.create("/atguigu", "dahaigezuishuai".getBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
System.out.println(path);
}
// 2 获取子节点 并监控节点的变化
@Test
public void getDataAndWatch() throws KeeperException, InterruptedException {
List<String> children = zkClient.getChildren("/", true);
for (String child : children) {
System.out.println(child);
}
Thread.sleep(Long.MAX_VALUE);
}
// 3 判断节点是否存在
@Test
public void exist() throws KeeperException, InterruptedException {
Stat stat = zkClient.exists("/atguigu", false);
System.out.println(stat == null ? "not exist" : "exist");
}
}
监听服务器节点动态上下线案例
需求：
某分布式系统中，主节点可以有多台，可以动态上下线，任意一台客户端都能实时感知到主节点服务器的上下线。
先在集群上创建/servers节点
[zk: localhost:2181(CONNECTED) 10] create /servers “servers”
Created /servers
服务器端
服务器端向Zookeeper注册代码
import org.apache.zookeeper.*;
import org.apache.zookeeper.ZooDefs.Ids;
import java.io.IOException;
public class DistributeServer {
public static void main(String[] args) throws Exception {
DistributeServer server = new DistributeServer();
// 1 连接zookeeper集群
server.getConnect();
// 2 注册节点
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 path = zkClient.create("/servers/server", hostname.getBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL);
System.out.println(hostname + " is online ");
}
private String connectString = "hadoop102:2181,hadoop103:2181,hadoop104:2181";
private int sessionTimeout = 2000;
private ZooKeeper zkClient;
private void getConnect() throws IOException {
zkClient = new ZooKeeper(connectString, sessionTimeout, new Watcher() {
@Override
public void process(WatchedEvent event) {
// TODO Auto-generated method stub
}
});
}
}
客户端
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 {
public static void main(String[] args) throws IOException, KeeperException, InterruptedException {
DistributeClient client = new DistributeClient();
// 1 获取zookeeper集群连接
client.getConnect();
// 2 注册监听
client.getChlidren();
// 3 业务逻辑处理
client.business();
}
private void business() throws InterruptedException {
Thread.sleep(Long.MAX_VALUE);
}
private void getChlidren() throws KeeperException, InterruptedException {
List<String> children = zkClient.getChildren("/servers", true);
// 存储服务器节点主机名称集合
ArrayList<String> hosts = new ArrayList<String>();
for (String child : children) {
byte[] data = zkClient.getData("/servers/" + child, false, null);
hosts.add(new String(data));
}
// 将所有在线主机名称打印到控制台
System.out.println(hosts);
}
private String connectString = "hadoop102:2181,hadoop103:2181,hadoop104:2181";
private int sessionTimeout = 2000;
private ZooKeeper zkClient;
private void getConnect() throws IOException {
zkClient = new ZooKeeper(connectString, sessionTimeout, new Watcher() {
@Override
public void process(WatchedEvent event) {
try {
getChlidren();
} catch (KeeperException e) {
e.printStackTrace();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
);
}
}
zk 面试题
- ZooKeeper文件系统
Zookeeper提供一个多层级的节点命名空间（节点称为znode）。
与文件系统不同的是，这些节点都可以设置关联的数据，而文件系统中只有文件节点可以存放数据而目录节点不行。
Zookeeper为了保证高吞吐和低延迟，在内存中维护了这个树状的目录结构，这种特性使得Zookeeper不能用于存放大量的数据，每个节点的存放数据上限为1M。
- 四种类型的znode
- 持久化节点
- 临时节点
- 持久化顺序节点
- 临时顺序节点
- Zookeeper通知机制
ZooKeeper的watcher机制，当ZNode的发生节点删除添加的操作或者节点内容发生改变，子节点的操作等，监听的Client会收到通知，然后我们可以在程序中进行自己进行处理
- 应用场景
1、命名服务
2、配置管理
3、集群管理
4、分布式锁
5、队列管理
- 命名服务
命名服务是指通过指定的名字来获取资源或者服务的地址，利用zk创建一个全局的路径，即是唯一的路径，这个路径就可以作为一个名字，指向集群中的集群，提供的服务的地址，或者一个远程的对象等等。
也就是我们常说的注册中心，进行服务的发布与消费，通过ZooKeeper协议进行服务的注册，将地址作为内容放到临时结点上，然后消费者可以通过ZooKeeper暴露出来的地址访问指定的服务名称获得服务的地址，然后服务间进行通信即可，与注册中心就无关了，一旦地址发生修改，ZooKeeper也会通过Watcher机制通知消费方修改地址，而且集群环境下只需要添加多个地址，然后再消费方程序中进行负载均衡算法的实现即可；
- 集群管理
所谓集群管理无在乎两点：是否有机器退出和加入、选举master。
对于第一点，所有机器约定在父目录下`创建临时目录节点，然后监听父目录节点的子节点变化消息。一旦有机器挂掉，该机器与 zookeeper的连接断开，其所创建的临时目录节点被删除，所有其他机器都收到通知：某个兄弟目录被删除，于是，所有人都知道：它下船了。
新机器加入也是类似，所有机器收到通知：新兄弟目录加入，highcount又有了，对于第二点，我们稍微改变一下，所有机器创建临时顺序编号目录节点，每次选取编号最小的机器作为master就好。
集群的管理主要有两点，机器的
加入与退出，Master的选举
对于第一点我们可以让所有机器约好在同一个父节点下面创建临时节点，然后都监听父节点的节点变化，一旦服务宕机，或者什么其他情况，临时节点创建或者消失就会被集群中其他的机器收到通知，因此可以实现集群中机器的加入和退出对所有的成员来说是可知的；而Master的选举我们可以通过顺序节点，一旦Master宕机就选择集群中编号最小的机器作为Master其他机器跟着新的Master走就可以了
- 统一配置管理
程序分布式的部署在不同的机器上，将程序的配置信息放在zk的znode下，当有配置发生改变时，也就是znode发生变化时，可以通过改变zk中某个目录节点的内容，利用watcher通知给各个客户端，从而更改配置。
将所有的配置文件都放在一个父节点下面，创建一个持久化节点，程序中只需要读取各自的配置文件信息即可，同时监听配置节点内容的修改，一旦内容修改就重启服务等系列的操作，实现了统一配置文件的处理
- 分布式锁
分为两种
- 保持独占锁
在业务逻辑之前，每次都去尝试创建一个临时节点，谁创建到了这个临时节点，谁就拿到了锁，进行相应的业务逻辑操作，在逻辑操作结束之后对节点进行销毁也就是释放锁即可
2.顺序执行锁
在业务逻辑之前，都在一个已经存在的节点下面创建一个临时顺序节点，保证每次都是顺序编号最小的节点进行业务逻辑操作，当逻辑操作结束后，删除该节点，然后继续是顺序编号最小的节点进行业务逻辑操作，同样可以保证每次都是只有一个节点也就是一个线程在进行逻辑操作
- 获得分布式锁的流程
在获取分布式锁的时候在locker节点下创建临时顺序节点，释放锁的时候删除该临时节点。客户端调用createNode方法在locker下创建临时顺序节点，
然后调用getChildren(“locker”)来获取locker下面的所有子节点，注意此时不用设置任何Watcher。客户端获取到所有的子节点path之后，如果发现自己创建的节点在所有创建的子节点序号最小，那么就认为该客户端获取到了锁。如果发现自己创建的节点并非locker所有子节点中最小的，说明自己还没有获取到锁，此时客户端需要找到比自己小的那个节点，然后对其调用exist()方法，同时对其注册事件监听器。之后，让这个被关注的节点删除，则客户端的Watcher会收到相应通知，此时再次判断自己创建的节点是否是locker子节点中序号最小的，如果是则获取到了锁，如果不是则重复以上步骤继续获取到比自己小的一个节点并注册监听。当前这个过程中还需要许多的逻辑判断。
- Zookeeper队列管理（文件系统、通知机制）
两种类型的队列：
1、同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。
2、队列按照 FIFO 方式进行入队和出队操作。
第一类，在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目。
第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。在特定的目录下创建PERSISTENT_SEQUENTIAL节点，创建成功时Watcher通知等待的队列，队列删除序列号最小的节点用以消费。此场景下Zookeeper的znode用于消息存储，znode存储的数据就是消息队列中的消息内容，SEQUENTIAL序列号就是消息的编号，按序取出即可。由于创建的节点是持久化的，所以不必担心队列消息的丢失问题。
- Zookeeper数据复制
Zookeeper作为一个集群提供一致的数据服务，自然，它要在所有机器间做数据复制。数据复制的好处：
1、容错：一个节点出错，不致于让整个系统停止工作，别的节点可以接管它的工作；
2、提高系统的扩展能力 ：把负载分布到多个节点上，或者增加节点来提高系统的负载能力；
3、提高性能：让客户端本地访问就近的节点，提高用户访问速度。
从客户端读写访问的透明度来看，数据复制集群系统分下面两种：
1、写主(WriteMaster) ：对数据的修改提交给指定的节点。读无此限制，可以读取任何一个节点。这种情况下客户端需要对读与写进行区别，俗称读写分离；
2、写任意(Write Any)：对数据的修改可提交给任意的节点，跟读一样。这种情况下，客户端对集群节点的角色与变化透明。
对zookeeper来说，它采用的方式是写任意。通过增加机器，它的读吞吐能力和响应能力扩展性非常好，而写，随着机器的增多吞吐能力肯定下降（这也是它建立observer的原因），而响应能力则取决于具体实现方式，是延迟复制保持最终一致性，还是立即复制快速响应。
- Zookeeper工作原理
Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。此时系统的不可用的，所以ZooKeeper采用的是CP原则
13.Zookeeper 下 Server工作状态
每个Server在工作过程中有
三种状态：
looking：当前Server不知道leader是谁，正在搜寻
leading：当前Server即为选举出来的leader
following：leader已经选举出来，当前Server与之同步
- zookeeper是如何保证事务的顺序一致性的？
两段协议，首先会向其他的server发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行。
- Zookeeper同步流程
1、Leader等待server连接；
2、Follower连接leader，将最大的zxid发送给leader；
3、Leader根据follower的zxid确定同步点；
4、完成同步后通知follower 已经成为uptodate状态；
5、Follower收到uptodate消息后，又可以重新接受client的请求进行服务了。
- 机器中为什么会有leader？
在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行，其他的机器可以共享这个结果，这样可以大大减少重复计算，提高性能，于是就需要进行leader选举。
- zk节点宕机如何处理？
Zookeeper本身也是集群，推荐配置不少于3个服务器。Zookeeper自身也要保证当一个节点宕机时，其他节点会继续提供服务。
如果是一个Follower宕机，还有2台服务器提供访问，因为Zookeeper上的数据是有多个副本的，数据并不会丢失；
如果是一个Leader宕机，Zookeeper会选举出新的Leader。
ZK集群的机制是只要超过半数的节点正常，集群就能正常提供服务。只有在ZK节点挂得太多，只剩一半或不到一半节点能工作，集群才失效。
- zookeeper负载均衡和nginx负载均衡区别
zookeeper
不存在单点问题，zab机制保证单点故障可重新选举一个leader
只负责服务的注册与发现，不负责转发，减少一次数据交换（消费方与服务方直接通信）
需要自己实现相应的负载均衡算法
nginx
存在单点问题，单点负载高数据量大,需要通过KeepAlived+LVS备机实现高可用
每次负载，都充当一次中间人转发角色，增加网络负载量（消费方与服务方间接通信）
自带负载均衡算法
参考
柳絮说zk
zk面试题
尚硅谷zk讲解
