Zookeeper

概述

基于观察者模式设计的分布式服务管理框架，为分布式应用提供协调服务的Apache项目
它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化， Zookeeper就将负责通知已经在Zookeepe上注册的那些观察者做出相应的反应
Zookeeper=文件系统+通知机制
- 文件系统：存储服务器的各种上线信息

特点

一个领导者（Leader），多个跟随者（Follower）组成的集群
集群中只要有半数以上节点存活，Zookeeper集群就能正常服务，适合安装基数台服务器
全局数据一致：每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据都是一致的
更新请求顺序进行：来自同一个Client的更新请求按其发送顺序依次执行
数据更新原子性：一次数据更新要么成功，要么失败
实时性：在一定时间范围内，Client能读到最新数据

数据结构

与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。每一个ZNode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识

应用场景

统一命名服务
- 在分布式环境下经常需要对应用/服务进行统一命名，便于识别
统一配置管理
- 分布式环境下，配置文件同步非常常见
  - 一般要求一个集群中，所有节点的配置信息是一致的，比如Kafka集群
  - 对配置文件修改后，希望能够快速同步到各个节点上
- 配置管理可交由ZooKeeper实现
  - 可将配置信息写入ZooKeeper上的一个Znode
  - 各个客户端服务器监听这个Znode
  - 一旦Znode中的数据被修改，ZooKeeper将通知各个客户端服务器
统一集群管理
- 分布式环境中，实时掌握每个节点的状态是必要的
  - 可根据节点实时状态做出一些调整
- ZooKeeper可以实现实时监控节点状态变化
  - 可将节点信息写入ZooKeeper上的一个ZNode
  - 监听这个ZNode可获取它的实时状态变化
服务器节点动态上下线
- 客户端能实时洞察到服务器上下线的变化
软负载均衡
- 在Zookeeper中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求

操作

官网首页：https://zookeeper.apache.org/

配置参数

tickTime = 2000：通信心跳时间，Zookeeper服务器与客户端心跳时间，单位毫秒
initLimit = 10：LF初始通信时限，Leader和Follower初始连接时能容忍的最多心跳数（tickTime的数量）
syncLimit = 5：LF同步通信时限，Leader和Follower之间通信时间。如果超过syncLimit * tickTime，Leader认为Follwer死掉，从服务器列表中删除Follwer
dataDir：保存Zookeeper中的数据
- 注意：默认的tmp目录容易被Linux系统定期删除，所以一般不用默认的tmp目录
clientPort = 2181：客户端连接端口，通常不做修改

集群安装

集群规划
安装
1. 配置修改
  1. 将/opt/module/zookeeper-3.5.7/conf这个路径下的 zoo_sample.cfg修改为zoo.cfg
    1
    mv zoo_sample.cfg zoo.cfg
  2. 打开zoo.cfg文件，修改dataDir路径
    1
    2
    3
    vim zoo.cfg # 修改如下内容 dataDir=/opt/module/zookeeper-3.5.7/zkData
  3. 在/opt/module/zookeeper-3.5.7/这个目录上创建zkData文件夹
    1
    mkdir zkData
2. 操作 Zookeeper
  1. 启动Zookeeper
    1
    bin/zkServer.sh start
  2. 查看进程是否启动
    1
    jps
  3. 查看状态
    1
    bin/zkServer.sh status
  4. 启动客户端
    1
    bin/zkCli.sh
  5. 退出客户端
    1
    quit
  6. 停止 Zookeeper
    1
    bin/zkServer.sh stop
配置服务器编号
1. 在/opt/module/zookeeper-3.5.7/这个目录下创建zkData
  1
  mkdir zkData
2. 在/opt/module/zookeeper-3.5.7/zkData目录下创建一个myid的文件
  1
  vim myid
3. 在文件中添加与server对应的编号（上下左右不要有空格/空行）
  1
  2

配置zoo.cfg文件

重命名/opt/module/zookeeper-3.5.7/conf这个目录下的 zoo_sample.cfg为zoo.cfg
1
mv zoo_sample.cfg zoo.cfg

打开zoo.cfg文件

vim zoo.cfg
# 修改数据存储路径配置
dataDir=/opt/module/zookeeper-3.5.7/zkData
# 增加如下配置
#######################cluster########################## 
server.2=hadoop102:2888:3888 server.3=hadoop103:2888:3888 server.4=hadoop104:2888:3888
# eg
server.1=172.17.0.2:2888:3888
server.2=172.17.0.3:2888:3888
server.3=172.17.0.4:2888:3888

配置参数解读

server.A=B:C:D
# A是一个数字，表示这个是第几号服务器
#			集群模式下配置一个文件myid，这个文件在dataDir目录下，这个文件里面有一个数据就是A的值
#			Zookeeper启动时读取此文件，拿到里面的数据与zoo.cfg 里面的配置信息比 较从而判断到底是哪个server
# B是这个服务器的地址
# C是这个服务器Follower与集群中的Leader服务器交换信息的端口
# D是万一集群中的Leader服务器挂了，需要一个端口来重新进行选举，选出一个新的Leader，而这个端口就是用来执行选举时服务器相互通信的端口

同步zoo.cfg配置文件
1
xsync zoo.cfg

集群操作

分别启动Zookeeper
1
bin/zkServer.sh start
查看状态
1
bin/zkServer.sh status

选举机制（重点）

SID：服务器ID，和myid一致。用来唯一标识一台ZooKeeper集群中的机器，每台机器不能重复
ZXID：事务ID，用来标识一次服务器状态的变更。在某一时刻，集群中的每台机器的ZXID值不一定完全一致，这和ZooKeeper服务器对于客户端“更新请求”的处理逻辑有关（Client每次写操作都有事务ID）
Epoch：每个Leader任期的代号。没有Leader时同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加
第一次启动
1. 服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为
  LOOKING
2. 服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息：此时服务器1发现服务器2的myid比自己目前投票推举的（服务器1）大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持LOOKING
3. 服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果:服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING
4. 服务器4启动，发起一次选举。此时服务器1，2，3已经不LOOKING状态，不会更改选票信息。交换选票信息结果:服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING
5. 服务器5启动，同4一样当小弟
非第一次启动
1. 当ZooKeeper集群中的一台服务器出现以下两种情况之一时，就会开始进入Leader选举
  - 服务器初始化启动
  - 服务器运行期间无法和Leader保持连接
2. 而当一台机器进入Leader选举流程时，当前集群也可能会处于以下两种状态
  - 集群中本来就已经存在一个Leader：机器试图去选举Leader时会被告知当前服务器的Leader信息，对于该机器来说，仅仅需要和Leader机器建立连接，并进行状态同步即可
  - 集群中确实不存在Leader：假设ZooKeeper由5台服务器组成，SID分别为1、2、3、4、5，ZXID分别为8、8、8、7、7，并且此时SID为3的服务器是Leader。某一时刻，3和5服务器出现故障，因此开始进行Leader选举，SID为1、2、4的机器投票情况为
    
    EPOCH ZXID SID
    
    1 8 1
    
    1 8 2
    
    1 7 4
    - 选举Leader规则
      1. EPOCH大的直接胜出
      2. EPOCH相同，事务id大的胜出
      3. 事务id相同，服务器id大的胜出

EPOCH	ZXID	SID
1	8	1
1	8	2
1	7	4

启动停止脚本

创建脚本并编辑

1	`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

增加脚本执行权限
1
chmod u+x zk.sh
操作脚本
1
zk.sh start

客户端命令行操作

语法
- help：显示所有操作命令
- ls path：使用ls命令来查看当前znode的子节点[可监听]
  - -w：监听子节点变化
  - -s：附加次级信息
- create：普通创建
  - -s：含有序列
  - -e：临时（重启或者超时消失）
  1
  2
  3
  create /sanguo "diaochan" create /sanguo/shuguo "liubei" create -s /sanguo/weiguo "caocao"
- get path：获得节点的值[可监听]
  - -w：监听节点内容变化
  - -s：附加次级信息
  1
  2
  get -s /sanguo get -s /sanguo/shuguo
- set：设置节点的具体值
- stat：查看节点状态
- delete：删除节点
- deleteall：递归删除节点
- zkCli.sh -server 机器名:2181：启动客户端

结点

详细数据
- czxid：创建节点的事务zxid
  - 每次修改ZooKeeper状态都会产生一个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子节点数量
类型节点
- 持久化目录节点（Persistent）：客户端与Zookeeper断开连接后，该节点依旧存在
  - 持久：客户端和服务器端断开连接后，创建的节点不删除
  - 不带序号不能重复创建
- 持久化顺序编号目录节点（Persistent_sequential）：客户端与Zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
  - 创建znode时设置顺序标识，znode名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护（能重复创建）
- 临时目录节点（Ephemeral）：客户端与Zookeeper断开连接后，该节点被删除
  - 短暂：客户端和服务器端断开连接后，创建的节点自己删除
- 临时顺序编号目录节点（Ephemeral_sequential）：客户端与Zookeeper断开连接后，该节点被删除，只是 Zookeeper给该节点名称进行顺序编号
- 在分布式系统中顺序号可以被用于为所有的事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序

监听器

过程
1. 首先有一个main()线程
2. 在main线程中创建Zookeeper客户端，这时会创建两个线程，一个负责网络连接通信（connet），一个负责监听（listener）
3. 通过connect线程将注册的监听事件发送给Zookeeper
4. 在Zookeeper的注册监听器列表中将注册的监听事件添加到列表中
5. Zookeeper监听到有数据或路径变化，就会将这个消息发送给listener线程
6. listener线程内部调用了process()方法
常见的监听
- 监听节点数据的变化：get path [watch]
- 监听子节点增减的变化：ls path [watch]
节点的值变化监听
1. zk3注册监听/sanguo节点数据变化
  1
  get -w /sanguo
2. zk2主机上修改/sanguo节点的数据
  1
  set /sanguo "xishi"
3. zk3主机收到数据变化的监听
  1
  2
  3
  WATCHER:: WatchedEvent state:SyncConnected type:NodeDataChanged path:/sanguo
- 注册一次只能监听一次，若想再次监听需要再次注册
节点的子节点变化监听（路径变化）
1. zk3主机上注册监听/sanguo节点的子节点变化
  1
  ls -w /sanguo
2. zk2主机/sanguo节点上创建子节点
  1
  create /sanguo/weiguo "simayi"
3. zk3主机收到子节点变化的监听
  1
  2
  3
  WATCHER:: WatchedEvent state:SyncConnected type:NodeChildrenChanged path:/sanguo
- 节点的路径变化也是注册一次生效一次。若想多次生效就需要多次注册

客户端API

前提：Zookeeper集群已经启动

pom

<!-- https://mvnrepository.com/artifact/org.apache.zookeeper/zookeeper -->
<dependency>
    <groupId>org.apache.zookeeper</groupId>
    <artifactId>zookeeper</artifactId>
    <version>3.7.0</version>
    <!-- log4j会与slf4j冲突, 在SpringBoot里需排除-->
    <exclusions>
        <exclusion>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-log4j12</artifactId>
        </exclusion>
    </exclusions>
</dependency>

zkClient

public class zkClient {

    // 连接哪个zookeeper, 字符串中逗号前后都不能有空格
    private static final String connectString = "localhost:21811,localhost:21812,localhost:21813";
    // 超时时间, 单位为ms
    private static final int sessionTimeout = 2000;
    private static ZooKeeper zkCli = null;

    /**
     * 创建客户端
     */
    @BeforeEach
    public void init() throws Exception {
        zkCli = new ZooKeeper(connectString, sessionTimeout, new Watcher() {
            // 监听器
            @Override
            public void process(WatchedEvent watchedEvent) {
                try {
                    System.out.println("+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=");
                    List<String> children = zkCli.getChildren("/", true);
                    children.forEach(System.out::println);
                    System.out.println("=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+");
                } catch (Exception e) {
                    e.printStackTrace();
                }
            }
        });
    }

    /**
     * 创建子节点
     */
    @Test
    public void create() throws Exception {
        // 参数1: 要创建的节点的路径; 参数2: 节点数据; 参数3: 节点权限; 参数4: 节点的类型
        String node = zkCli.create(
                "/cc/mousse",
                "PhineasZ".getBytes(StandardCharsets.UTF_8),
                ZooDefs.Ids.OPEN_ACL_UNSAFE,
                CreateMode.PERSISTENT
        );
        log.info("node: {}", node);
    }

    /**
     * 获取子节点
     */
    @Test
    public void getChildren() throws Exception {
//        List<String> children = zkCli.getChildren("/", true);
//        children.forEach(System.out::println);
        // 延时
        Thread.sleep(Long.MAX_VALUE);
    }

    /**
     * 判断是否存在
     */
    @Test
    public void exist() throws Exception {
        Stat stat = zkCli.exists("/cc/mousse", false);
        System.out.println(stat == null ? "not exist" : "exist");
    }

}

原理

读写原理

写入流程
- 请求直接发送给Leader节点
  1. Client → write → Leader
  2. Leader → write → Follower1
  3. Follower1 → ack → Leader
  4. 若过半数：Leader → ack → Client
  5. Leader → write → Follower2
  6. Follower2 → ack → Leader
  7. ……
- 请求发送给Follower1节点
  1. Client → write → Follower1
  2. Follower1 → write请求 → Leader
  3. Leader → write → Follower1
  4. Follower1 → ack → Leader
  5. 若过半数：Leader → ack → Follower1
  6. Follower1 → ack → Client
  7. Leader → write → Follower2
  8. Follower2 → ack → Leader
  9. ……

案例

动态上下线

过程
1. 服务端启动时注册信息（创建临时节点）
2. 客户端获取当前在线服务器列表并注册监听
3. 服务器节点下线
4. 服务器节点上下线事件通知
- 所谓服务器和客户端对于Zookeeper来说都是客户端，所谓服务器注册消息（create），所谓客户端监听消息（watch）

实现

Zookeeper上创建节点/servers

Client

public class DistributeClient {

    private static ZooKeeper zk = null;
    private static final String connectString = "localhost:21811,localhost:21812,localhost:21813";
    private static final int sessionTimeout = 2000;

    public static void main(String[] args) throws Exception {
        // 获取zk连接
        getConnect();
        // 监听节点变化
        getServerList();
        // 业务逻辑(睡觉)
        business();
    }

    private static void business() throws Exception {
        Thread.sleep(Long.MAX_VALUE);
    }

    private static void getConnect() throws Exception {
        zk = new ZooKeeper(connectString, sessionTimeout, watchedEvent -> {
            try {
                // 监听完毕后再次调用
                getServerList();
            } catch (Exception e) {
                e.printStackTrace();
            }
        });
    }

    public static void getServerList() throws Exception {
        List<String> children = zk.getChildren("/servers", true);
        List<String> servers = new ArrayList<>();
        for (String child : children) {
            byte[] data = zk.getData("/servers/" + child, false, null);
            servers.add(new String(data));
        }
        servers.forEach(System.out::println);
    }
    
}

Server

public class DistributeServer {

    private static ZooKeeper zk = null;
    private static final String connectString = "localhost:21811,localhost:21812,localhost:21813";
    private static final int sessionTimeout = 2000;
    private static final String hostname = "Server1";

    public static void main(String[] args) throws Exception {
        // 获取zk连接
        getConnect();
        // 注册服务器到zk集群
        register(hostname);
        // 启动业务逻辑(睡觉)
        business();
    }

    private static void business() throws Exception {
        Thread.sleep(Long.MAX_VALUE);
    }

    private static void getConnect() throws Exception {
        zk = new ZooKeeper(connectString, sessionTimeout, watchedEvent -> {
        });
    }

    private static void register(String hostname) throws Exception {
        zk.create(
                "/servers/" + hostname,
                hostname.getBytes(StandardCharsets.UTF_8),
                ZooDefs.Ids.OPEN_ACL_UNSAFE,
                CreateMode.EPHEMERAL_SEQUENTIAL
        );
        log.info("host {} is online", hostname);
    }
    
}

分布式锁

过程
1. 接受到请求后在/locks节点下创建一个临时顺序节点
2. 判断自己是不是当前节点下最小的节点
  - 是：获取到锁
  - 否：对前一个节点进行监听
3. 获取到锁，处理完业务后delete节点释放锁，然后下面的节点将收到通知重复第二步判断

Curator框架实现

Curator是一个专门解决分布式锁的框架，解决了原生Java API开发分布式遇到的问题。详情请查看官方文档:https://curator.apache.org/index.html

依赖

<!-- https://mvnrepository.com/artifact/org.apache.curator/curator-framework -->
<dependency>
    <groupId>org.apache.curator</groupId>
    <artifactId>curator-framework</artifactId>
    <version>5.2.0</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.apache.curator/curator-recipes -->
<dependency>
    <groupId>org.apache.curator</groupId>
    <artifactId>curator-recipes</artifactId>
    <version>5.2.0</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.apache.curator/curator-client -->
<dependency>
    <groupId>org.apache.curator</groupId>
    <artifactId>curator-client</artifactId>
    <version>5.2.0</version>
</dependency>

代码

public class CuratorLockTest {

    public static void main(String[] args) {
        // 创建分布式锁1
        InterProcessMutex lock1 = new InterProcessMutex(getCuratorFramework(), "/locks");
        // 创建分布式锁2
        InterProcessMutex lock2 = new InterProcessMutex(getCuratorFramework(), "/locks");
        new Thread(() -> {
            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(() -> {
            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() {
        // 创建客户端
        CuratorFramework client = CuratorFrameworkFactory
                .builder()
                .connectString("localhost:21811,localhost:21812,localhost:21813")
                .connectionTimeoutMs(2000)
                .sessionTimeoutMs(2000)
                // 重试策略
                .retryPolicy(new ExponentialBackoffRetry(3000, 3))
                .build();
        // 启动
        client.start();
        System.out.println("Zookeeper启动成功");
        return client;
    }

}

面试真题

选举机制

半数机制：超过半数的投票通过，即通过
第一次启动选举规则：投票过半数时，服务器id大的胜出
第二次启动选举规则
1. EPOCH大的直接胜出
2. EPOCH相同，事务id大的胜出
3. 事务id相同，服务器id大的胜出

生产集群安装数量

安装奇数台
生产经验
- 10台服务器：3台zk
- 20台服务器：5台zk
- 100台服务器：11台zk
- 200台服务器：11台zk
服务器台数多
- 好处：提高可靠性
- 坏处：提高通信延时

常用命令

ls、get、create、delete

算法

Paxos算法

一种基于消息传递且具有高度容错特性的一致性算法
解决的问题：如何快速正确的在一个分布式系统中对某个数据值达成一致，并且保证不论发生任何异常，都不会破坏整个系统的一致性
描述
- 所有节点划分为Proposer（提议者），Acceptor（接受者）和
  Learner（学习者）（每个节点都可以身兼数职）
- 三个阶段
  1. Prepare准备阶段
    1. Proposer向多个Acceptor发出Propose请求Promise（承诺）
    2. Acceptor针对收到的Propose请求进行Promise（承诺）
  2. Accept接受阶段
    1. Proposer收到多数Acceptor承诺的Promise后，向Acceptor发出Propose请求
    2. Acceptor针对收到的Propose请求进行Accept处理
  3. Learn学习阶段：Proposer将形成的决议发送给所有Learners
流程
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
问题
- 系统中有一个以上的Proposer，多个Proposers相互争夺Acceptor造成迟迟无法达成一致的情况，针对这种情况，一种改进的Paxos算法被提出：从系统中选出一个节点作为Leader，只有Leader能够发起提案。这样一次Paxos流程中只有一个Proposer，不会出现活锁的情况

ZAB协议

改进的Paxos算法：系统中选一个节点作为Leader，只有Leader能够发起提案
两种基本的模式：消息广播、崩溃恢复
消息广播
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消息后，会将上一条事务提交
- Zookeeper采用ZAB协议的核心，就是只要有一台服务器提交了Proposal，就要确保所有的服务器最终都能正确提交Proposal
崩溃恢复
1. 异常假设
  - 一旦Leader服务器出现崩溃或者由于网络原因导致Leader服务器失去了与过半Follower的联系，那么就会进入崩溃恢复模式
  - ZAB协议崩溃恢复要求满足一下要求
    - 确保已经被Leader提交的提案Proposal，必须最终被所有的Follower服务器提交（已经产生的提案，Follower必须执行）
    - 确保丢弃已经被Leader提出的，但是没有被提交的Proposal（丢弃胎死腹中的提案）
2. Leader选举
  - 新选举出来的Leader不能包含未提交的Proposal（新Leader必须都是已经提交了Proposal的Follower服务器节点）
  - 新选举的Leader节点中含有最大的zxid，（有最新的操作）
3. 数据恢复
  1. 完成Leader选举后，在正式开始工作之前（接收事务请求，然后提出新的Proposal），Leader服务器会首先确认事务日志中的所有的Proposal是否已经被集群中过半的服务器Commit
  2. Leader服务器需要确保所有的Follower服务器能够接收到每一条事务的Proposal，并且能将所有已经提交的事务Proposal 应用到内存数据中。等到Follower将所有尚未同步的事务Proposal都从Leader服务器上同步过并且应用到内存数据中以后，Leader才会把该Follower加入到真正可用的Follower列表中

CAP理论

CAP理论：一个分布式系统不可能同时满足以下三种基本需求，最多只能同时满足其中的两项，因为P是必须的，因此往往选择就在CP或者AP中
- 一致性：Consistency
  - 数据在多个副本之间是否能够保持数据一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态
- 可用性：Available
  - 系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能在有限的时间内返回结果
- 分区容错性：Partition Tolerance
  - 分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障
ZooKeeper保证的是CP
- ZooKeeper不能保证每次服务请求的可用性（在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果）
- 进行Leader选举时集群都是不可用

后端大数据

Zookeeper

http://docs.mousse.cc/Zookeeper/

作者

Mocha Mousse

发布于

2024年11月26日

许可协议

Spring注解开发上一篇

Spring 下一篇