zookeeper指北

刺骨的言语ヽ痛彻心扉 2022-11-08 14:25 343阅读 0赞

# zookeeper指北 #

1.  zookeeper是什么
2.  zookeeper可以做什么
3.  zookeeper实战
4.  zookeeper原理

# 1.zookeeper是什么 #

一个分布式协调服务框架，简单点来说就是= **文件系统 + 监听通知机制**

定位更多的用到：服务注册中心

# 2. zookeeper可以做什么 #

可以用来解决分布式应用中经常遇到的一些数据管理问题如：

1.  统一命名服务（分布式唯一Id生成器）
2.  分布式锁
3.  服务注册中心
4.  配置中心

## 分布式锁 ##

分布式锁三个特点：多**进程**可见、互斥、可重入

利用zk所有写入都顺序经过leader实现分布式锁。 具体实现思路：

1.  创建一个永久节点
2.  在这个永久节点下创建临时顺序节点
3.  按照临时节点的序号获得锁
4.  每个请求处理完成删除临时节点

注意：临时节点只需要监听前一个节点，可以防止羊群效应；使用临时顺序节点可以避免因为意外会话关闭，而节点没有被删除导致死锁。  
缺点： 性能有瓶颈，相当于单机,不支持大规模并发

自己实现上面代码需要考虑很多细节异常处理，可以使用Curator框架实现。

/** * 使用 curator实现zk分布式锁 * * Guava is to Java that Curator to Zookeeper * * @author xuelongjiang * @description **/
    public class CuratorDistributeLock { 
    
        CuratorFramework client;
        InterProcessMutex lock;
    
        public CuratorDistributeLock() { 
            RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
             client = CuratorFrameworkFactory.newClient("127.0.0.1:2181",
                        5000, 5000, retryPolicy);
             client.start();
            lock = new InterProcessMutex(client, "/goods/lock");
        }
        
        public boolean lock() { 
            try { 
                lock.acquire();
                return true;
            } catch (Exception e) { 
                e.printStackTrace();
            }
            return false;
        }
    
        public void unlock() { 
            try { 
                lock.release();
            } catch (Exception e) { 
                e.printStackTrace();
            }
        }
    }

## 配置中心 ##

可以用来管理公共的配置，当配置修改不需要重启多台服务器，只需要修改zk上保存的配置值，应用监听到修改后更新值。

对应的配置中心还有：apollo（携程阿波罗）,etcd,spring-cloud-config, diamond, disconf, nacos

[统一配置中心选型比较][Link 1]

## 服务注册中心 ##

分布式服务中，不同集群之间通信，为了便于管理，引入服务注册中心。

### 直接通信： ###

集群A调用集群B，所以集群A每个实例保存了集群B所有的机器连接信息。  
每次调用，集群A实例中通过负载均衡算法调用集群B中其中一台。  
当集群B中某台机器失效了，依然还会调用。

### 使用注册中心 ###

集群B中的实例上线后，保存机器群到ZK的节点，集群A从ZK的节点读取当前  
有效的机器，当集群B中有机器下线了，zk删除对应的节点，集群A的所有实例监听到  
变化更新自己缓存的集群B的机器信息

[注册中心介绍介绍][Link 2]

## 统一命名服务（分布式唯一Id生成器） ##

利用zk中顺序节点的特性，制作分布式的序列号生成器(Id生成器)。  
在DB没有拆表的时候可以利用db主键唯一性生成id,但是当拆表后，同一个业务表  
有多个，uuid也可以但是uuid时无序的很难理解，那么此时可以使用zk来获取顺序的id

[zk实现命名服务][zk]  
[JNDI][]

JNDI: java naming and directory interface, 说白了就是把资源取个名字，再根据名字找资源

# 3. 实战 #

## 创建设置读取节点 ##

### 创建如下节点： ###

--maven
    -------name：xue
    -------pass: 123

### 创建节点： ###

create /maven/name
    
    create /maven/pass

### 节点设置值： ###

set /maven/name xue 
    set /maven/pass 123

### 获取节点值: ###

get /maven/name
    get /maven/pass

## 创建四种类型节点 ##

// 创建持久节点
     create  /nodename  
     //创建临时节点
     create -e  /nodename
     // 创建持久顺序节点 
     create -s /nodename 
     //创建临时顺序节点
     create -s -e /nodename

临时节点： 当前会话关闭后节点会自动被删除  
顺序节点：节点从0000000000开始创建子节点，每次计数增加一

**持久节点 + 临时顺序节点 可以实现分布式锁**  
**持久节点 + 临时节点 可以实现服务注册中心**

## 配置文件参数解析 ##

### tickTime: ###

心跳时间，服务端之间或客户端与服务端之间维持心跳的时间间隔，单位毫秒；

### initLimit ###

服务端集群中连接到leader的follower初始化连接时最长能忍受多少个心跳时间间隔数，当超过initLimit\*tickTime时间  
后还没有收到follower的返回信息，表示这个follower连接失败

### syncLimit ###

leader与follower之间发送消息，请求和应答时间长度，最长不能超过syncLimit\*tickTime时间；

### dataDir ###

zk保存数据的目录，默认也将写日志放在这个目录下

### clientPort ###

客户端连接zk服务的端口，zk服务会监听这个端口，接受客户端的访问s

### server.n=B: C: D ###

n： 是一个数字，表示第几号服务器  
B: 集群的ip地址们(有几台就有几号服务器)  
C: 与leader服务器交换信息的端口  
D: 如果leader挂了，用这个端口来选举新leader

# 4. zk的架构及其角色 #

## 角色 ##

1.  leader : 负责处理写请求，并且广播结果给所有的learn
2.  learn(follower + observer) : 用来接受客户端的请求，将写请求转发给leader
    
     *  follower: 参与选leader的投票
     *  observer: 只同步leader的状态，不参与选举leader，加入observer的  
        目的为了扩展zk系统的读能力

原子广播: 保证各各个server之间状态是统一的，实现这个机制的协议是zab协议

1.  zab协议两种模式: 恢复模式和广播模式

*  恢复模式：选主模式
 *  广播模式：同步leader的状态给所有的learn

zid：64位 = 高32位(epoch标识当前的leader) + 低32位(用于递增计数)

server的三种状态:

1.  looking: 寻找当前leader中
2.  leading: 当前server就是集群中的lead
3.  following: 已发现leader，当前server与之同步

zk特点：

1.  一个集群中只有一个leader
2.  每个server保存一份数据副本
3.  全局数据一致
4.  分布式读写
5.  写请求转发到leader,由leader实施

# 5. zk原理 #

## paxos算法 ##

基于消息传递的一致性算法;paxos有一个前提：没有拜占庭将军问题，就是说  
paxos只有一个可信的计算环境中才能成立，这个环境是不会被入侵所破坏的。

## paxos场景 ##

在一个小岛上，有一定数量的议员，所有的事情由他们投票决定。岛上每一次环境事务的变更都需要通过一个提议(proposal)，每个提议都有一个编号(xid)，这个编号一直增长，不能倒退，每次提议需要超过半数（n/2+1）的议员同意才能生效。每个议员只会同意大于当前编号的提议，小于的统一会拒绝。

## paxos示例 ##

现在我们开始运行一下这个算法，小岛上有3个议员s1,s2,s3，所有议员的笔记本上编号都是0，现在s1提议电费1度/元，s1看了看自己当前最大的编号，然后发起1号提议，s2收到1号提议，看了看自己的笔记本当前 最大的编号是0，于是记录这个提议，并告诉s1统一你的提案,此时s1统计收到了两个议员的同意(自己和s2)，已经大于当前一半的议员，提议生效,作为正式法令，广播给所有的议员。这里可能有一个冲突，我们看看paxos如何解决的：还是这个小岛有三个议员s1,s2,s3，和上面一样，不同的是在s1发起提议的时候，s2也发起了，s1：发起1号提议电费1度/元；s2：发起1号提议电费2度/元，此时s3首先收到s1的提案，同意了s1的提案，s2的提议到达s3，s3发现自己当前已经同意了1号提议，直接拒绝，(每个议员只会同意大于自己记录的最大编号)s1拿到了2票，大于集群一半，立即广播所有集群，记录下1号提议，此时所有议员的当前最大的编号都是1。

## paxos与zk的对应 ##

小岛 --> zk集群  
议员 --> zk server  
提议 --> znode change(create, delete,setData)  
提议编号 --> zid  
正式法令 --> 所有node及其数据

实际上zk是有一个leader的概念，由他来发起提议（也就是所有写操作都要转到leader）,为什么需要leader呢为了避免活锁引入leader,

# 6.常见问题 #

## zk写为什么半数以上确认就可以了，那剩下的机器数据一直不同步怎么办 ##

一直不同步的机器leader会把其踢出集群，有session超时机制的，follower感知网络出问题后会进入looking状态，重新建立和leader的链接，然后同步有差异的数据。

cap：  
一致性 consistemcy  
可用性 availability  
分区容错性 partition tolerance

redis： ap  
zk: cp

## zk是一致性的吗 ##

zk核心算法paoxs是目前唯一的分布式一致性算法，zk满足cap原则cp即一致性，分区容错性(分布式应用基本是，同一份数据多处保存)，但不是强一致性，只能满足最终一致性。  
zk使用zab协议进行leader与learn数据同步，Zab协议认为只要过半节点写入成功，数据就算写入成功，然后会告诉客户端A数据写入成功，如果这个时候客户端B恰好访问到还没有同步最新数据的zk节点，那么  
读到的数据就是不一致性的，因此zk无法保证数据的强一致性，只能保证最终一致性，而且可以保证同一客户端的顺序一致性。

## 如何实现真正的强一致性？ ##

zk既然不是强一致性的，那我们如何能保证两个客户端读到的数据是一致性的呢，那就是sync方法，zk原生客户端api和curator客户端都提供了该sync方法，调用sync方法之后，zk集群会保证集群所有节点数据都是一致性的，此时客户端再去任意节点读取数据，都能读到最新的数据

zk不保证强一致性的原因，我认为是可用性和一致性做了取舍。

1.  如果节点之间存在网络延迟，而又要所有节点都同步数据才算成功，那么写性能非常差
2.  如果一个节点挂了，无法同步数据，那么此时整个集群就无法提供服务，无法保证可用性（引入分布式系统就是为了满足高可用性）

## 分布式锁zk和redis的区别 ##

cap：  
一致性 consistemcy  
可用性 availability  
分区容错性 partition tolerance

zk保证cp, redis保证ap; zk锁靠谱，就是性能不行，不适合c端用户级别的锁。  
reids和zk应该都是base，zk也不是强一致性，读也有可能读到过期数据,也属于最终  
一致性，C还没拉满到强一致性(除非都读leader)，另外zk挂几台(没超过一半)也  
同样可以继续服务，A也有一定保障，  
只能说Redis可用性拉高一点，一致性拉低一点  
zk则一致性拉高一点，可用性拉低一点

## 为什么zk要部署奇数台服务器 ##

在zk集群中，如果宕掉了几台机器，剩下的机器大于集群总数的n/2，集群仍然可以继续提供服务，zk集群最少是3台机器组成，如果是2台，其中一台宕掉了，只剩下1台，不大于集群总数的1/2，因此最少需要3台集群，这里集群的容忍度是1，如果是4台机器，宕掉一台，还有3台可以继续提供服务，集群的容忍度还是1，从节约机器资源的角度看，没必要部署偶数个服务，3台的效果和4台一样，5台的效果和6台一样。

# 参考 #

[Zookeeper入门看这篇就够了][Zookeeper]  
[zk官方文档][zk 1]  
[七张图彻底讲清楚ZooKeeper分布式锁的实现原理][ZooKeeper]  
[3种Redis分布式锁的对比][3_Redis]  
[Zookeeper工作原理（详细）][Zookeeper 1]  
[Zookeeper全解析——Paxos作为灵魂][Zookeeper_Paxos]  
[Paxos算法详解][Paxos]  
[死锁、活锁、饥饿][Link 3]  
[zookeeper是强一致性的吗][zookeeper]  
[ZooKeeper常见问题][ZooKeeper 1]

[Link 1]: https://www.cnblogs.com/xiaoqi/p/configserver-compair.html
[Link 2]: https://www.cnblogs.com/MicroHeart/p/10389597.html
[zk]: https://blog.csdn.net/ZuoAnYinXiang/article/details/50946646
[JNDI]: https://blog.csdn.net/wn084/article/details/80729230
[Zookeeper]: https://blog.csdn.net/java_66666/article/details/81015302
[zk 1]: https://zookeeper.apache.org/doc/current/zookeeperOver.html
[ZooKeeper]: https://www.cnblogs.com/ysw-go/p/11444993.html
[3_Redis]: https://www.cnblogs.com/wlwl/p/11651409.html
[Zookeeper 1]: https://www.cnblogs.com/raphael5200/p/5285583.html
[Zookeeper_Paxos]: https://www.douban.com/note/208430424/
[Paxos]: https://blog.csdn.net/omnispace/article/details/79653932
[Link 3]: https://blog.csdn.net/qq_22054285/article/details/87911464
[zookeeper]: https://blog.csdn.net/trntaken/article/details/108949114
[ZooKeeper 1]: https://www.cnblogs.com/boothsun/p/8977028.html