zookeeper指北

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

统一配置中心选型比较

服务注册中心

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

直接通信：

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

使用注册中心

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

注册中心介绍介绍

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

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

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