Zookeeper
Zookeeper
Zookeeper是一个开源的分布式的，为分布式框架提供协调服务的Apache项目
Zookeeper
Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。
Zookeeper=文件系统+通知机制
特点
1）一个领导者（Leader），多个跟随者（Follower）组成的集群
2）集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。所以Zookeeper适合安装奇数台服务器。
3）全局数据一致：每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据都是一致的。
4）更新请求顺序执行，来自同一个Client的更新请求按其发送顺序依次执行
5）数据更新原子性，依次数据更新要么成功，要么失败。
6）实时性，在一定时间范围内，Client能读到最新数据。
数据结构
Zookeeper数据模型的结构整体上可以看作是一棵树，每个节点称作一个ZNode。每一个ZNode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识。
应用场景
提供的服务包括：统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等
统一命名服务
在分布式环境下，经常需要对应用服务进行统一命名，便于识别
统一配置管理
1）分布式环境下，配置文件同步非常常见
（1）一般要求一个集群中，所有节点的配置信息是一致的。
（2）对配置文件修改后，希望能够快速同步到各个节点上。
2）配置管理可交由Zookeeper实现。
（1）可将配置信息写入Zookeeper上的一个Znode
（2）各个客户端服务器监听这个Znode。
（3）一旦Znode中的数据被修改，Zookeeper将通知各个客户端服务器
统一集群管理
ZooKeeper可以实现实时监控节点状态变化
1)可将节点信息写入ZooKeeper上的一个ZNode
2）监听这个ZNode可获取它的实时状态变化
服务器动态上下线
客户端能实时洞察到服务器上下线的变化
软负载均衡
在Zookeeper中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求
配置参数解读
1）tickTime=2000：通信心跳时间，Zookeeper服务器与客户端心跳时间，单位毫秒
2）initLimit=10：LF初始通信时限，即Leader和Follower初始连接时能容忍的最多心跳数
3）syncLimit=5：LF同步通信时限，Leader和Follower之间通信时间如果超过syncLimit*tickTime，Leader认为Follower死掉，从服务器列表中删除Follower
4）dataDir：保存Zookeeper中的数据
5）clientPort=2181：客户端连接端口，通常不修改
集群
在集群的服务器上安装好Zookeeper后，在保存Zookeeper数据的目录下创建一个myid的文件，文件中写入与server对于的编号。
在配置中需要加入配置server.A=B.C.D
A是一个数字，表示这是第几号服务器
B是这个服务器的地址
C是这个服务器Follower与集群 中的Leader服务器交换信息的端口
D是万一集群中的Leader服务器挂了，需要一个端口来重新进行选举，选出一个新的Leader，而这个端口就是用来执行选举时服务器相互通信的端口。
Zookeeper选举机制——第一次启动
只有当leader挂了之后，才会重新进行选举。
每次读写操作都有事务id（zxid）
SID：服务器ID。用来唯一标识一台ZooKeeper集群中的机器，每台机器不能重复，和myid一样
ZXID：事务ID。ZXID是一个事务ID，用来标识一次服务器状态的变更。在某一时刻，集群中的每台机器的ZXID值不一定完全一致，这和ZooKeeper服务器对于客户端“更新请求”的处理逻辑有关。
Epoch：每个Leader任期的代号。没有Leader时同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加。
Zookeeper选举机制——非第一次启动
1)当Zookeeper集群中的一台服务器出现以下两种情况之一时，就会开始进入Leader选择：
- 服务器初始化启动
- 服务器运行期间无法和Leader保持连接
2）当一台机器进入Leader选举流程时，当前集群也可能会处于以下两种状态： - 集群中本来就已经存在一个Leader
对于第一种已经存在Leader的情况，机器试图去选举Leader时，会被告知当前服务器的Leader信息，对于该机器来说，仅仅需要和Leader机器建立连接，并进行状态同步即可。 - 集群中确实不存在Leader
节点信息
1）czxid：创建节点的事务zxid
2）ctime：znode被创建的毫秒数（从1970年开始）
3）mzxid：znode最后更新的事务zxid
4）mtime：znode最后修改的毫秒数（1970开始）
5）pZxid：znode最后更新的子节点zxid
6）cversion：znode子节点的变化号，znode子节点修改次数
7）dataversion：znode数据变化号
8）aclVersion：znode访问控制列表的变化号
9）ephemeralOwner：如果是临时节点，这个是znode拥有者的sessionid。如果不是临时节点则是0
10）dataLength：znode的数据长度
11）numChildren：znode子节点数量
节点类型（持久/短暂/有序号/无序号）
持久(Persistent)节点：客户端和服务器端断开连接后，创建的节点不删除。
短暂(Ephemeral)节点：客户端和服务器端断开连接后，创建的节点自己删除。
监听器原理
1）首先有一个main()线程
2）在main线程中创建Zookeeper客户端，这时就会创建两个线程，一个负责网络连接通信（connect），一个负责监听（listener）
3）通过connect线程将注册的监听事件发送给Zookeeper
4）在Zookeeper的注册监听器列表中将注册的监听事件添加到列表中
5）Zookeeper监听到有数据或路径变化，就会将这个消息发送给listener线程
6）listener线程内部调用了process()方法
多次修改节点的值，注册了监听的服务器只会收到一次修改提醒，因为注册一次，只能监听一次。想再次监听，需要再次注册。
常用命令
| 序号 | 命令及描述 |
|---|---|
| 1 | create <节点名> <节点信息> 创建节点 |
| 2 | delete <节点名> 删除节点 ，如果节点下有子节点无法删除 |
| 3 | deleteall <节点名> 删除节点及其子节点 |
| 4 | stat <节点名> 查看节点状态 |
| 5 | ls <节点名> 查看节点列表 |
写数据原理
请求直接发送给Leader节点
客户端访问Leader节点，并写入数据，Leader节点收到数据后先在本机上写一份数据，然后通知其它Follower节点写入数据，每一个Followe节点写完数据后通知Leader节点已写入数据。当集群中超过一半的节点写完数据后，Leader节点就返回信息给客户端通知数据已写完，可以进行后续操作。同时继续通知集群中还没写入数据的Follower节点继续写入数据。
请求发送给Follower节点
由于Follower节点没有写权限，会先把请求转发给Leader节点，Leader节点写入数据后，通知其它Follower节点写入数据，每一个Follower节点写完数据后通知Leader节点已写入数据。当集群中超过一半的节点写完数据后，Leader节点就返回信息给原来接收请求的Follower节点，通知其数据已写入完毕，Follower节点再返回信息通知客户端。同时，Leader节点继续通知其它Follower节点写入数据。
Zookeeper分布式锁
比如“进程1"在使用该资源的时候，会先去获得锁，”进程1“获得锁以后会对该资源保持独占，这样其它进程就无法访问该资源，”进程1“用完该资源以后就释放掉，让其他进程来获得锁，那么通过这个锁机制，我们就能保证了分布式系统中多个进程能够有序的访问该临界资源。那么我们就把这个分布式环境下的锁叫做分布式锁。
Curator框架实现分布式锁
1）原生的Java API开发存在的问题
? （1）会话连接是异步的，需要自己去处理。比如使用CountDownLatch
? （2）Watch需要重复注册，不然就不能生效
? （3）开发的复杂性比较高
? （4）不支持多节点删除和创建。需要自己去递归
2）Curator是一个专门解决分布式锁的框架，解决了原生Java API开发分布式遇到的问题。
3）案例实现
? （1）添加依赖
<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>
（2）实现代码
package redis.test.zk.case3;
import org.apache.curator.framework.CuratorFramework;
import org.apache.curator.framework.CuratorFrameworkFactory;
import org.apache.curator.framework.recipes.locks.InterProcessMutex;
import org.apache.curator.retry.ExponentialBackoffRetry;
public class CurrentLockTest {
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("192.168.60.135:2181")
.connectionTimeoutMs(2000)
.sessionTimeoutMs(2000)
.retryPolicy(policy).build();
//启动客户端
client.start();
System.out.println("zookeeper 启动成功");
return client;
}
}
选举机制
1）第一次启动时的选举规则：投票过半数时，服务器id大的胜出
2）第二次启动选举规则：①EPOCH大的直接胜出；②EPOCH相同，事务id(ZXID)大的胜出；③事务id相同，服务器id(SID)大的胜出。
生产集群安装多少zk合适？
生产经验：10台服务器：3台zk；20台服务器：5台zk；100台服务器：11台zk；200台服务器：11台zk。
安装奇数台，服务器台数多可以提高可靠性，但是会提高通信延时。