Zookeeper 理论总结

向右看齐 2023-02-14 01:54 111阅读 0赞

### 目录 ###

*   *   *  zk的数据模型
         *  zk server的集群模式
         *  zk的工作原理
         *  leader的选举机制
         *  zk的节点同步流程
         *  zk server如何处理客户端的请求
         *  zk的特点
         *  zk的心跳机制
         *  zk的watcher机制
         *  zk实现分布式通知、协调
         *  acl 权限控制

### zk的数据模型 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70]  
树结构，/是根节点，节点叫做znode，一个znode对应一个文件目录。

**有四种类型的znode**

*  PERSISTENT 持久，znode创建后一直保留
 *  PERSISTENT\_SEQUENTIAL 持久、顺序编号
 *  EPHEMERAL 临时，创建znode的zk client断开与zk server的连接后，zk server会自动删除该znode
 *  EPHEMERAL\_SEQUENTIAL 临时、顺序编号

临时节点常用于实现分布式锁。

### zk server的集群模式 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70 1]

**zk server有3种角色**

*  leader  负责处理zk client的写（、读）请求，一个zk集群只有一个leader
 *  follower  同步leader的数据，负责处理zk client的读请求，并参与leader的选举
 *  observer  负责处理zk client的读请求，但不参与leader的选举

zk集群是读写分离的模式，leader负责写（也可以处理读），follower负责读。

**有follower就够了，为什么还要使用observer？**

1、提高并发负载

observer可以协助 follower 处理更多的读请求，提高读请求的吞吐量

2、减少选举的时间花销

eg. follower5个、observer6个，选举leader只需要等待3台机器同意；如果11个全是follower，需要等待6个同意，大大增加了选举的时间花销。

3、提高集群可用性

down掉一半集群不可用，指的是followerdown掉一半，observer不参与数量统计，就算observer全部宕掉，也没关系。

eg. follower5个、observer8个，down掉所有observer、2个follower总共10个，集群仍然可用；如果13个全是follower，宕掉7个集群就不可用，显然使用observer可用性更高。

**zk server集群至少需要3个zk server，为什么官方推荐参与集群的zk server数量为奇数？**

因为单数、双数的容灾能力一样，少用一台机器还可以节约成本。

eg. zk server数量为5，down掉3个集群就不可用；数量为6，还是down3个集群就不可用。容灾能力（可用性）一样，少用1台机器还节约了成本。

### zk的工作原理 ###

zk的核心机制是原子广播，这个机制保证了节点之间的数据同步。

zk使用Zab协议实现原子广播，Zab协议有2种模式

*  恢复模式：leader故障后自动进入恢复模式，将集群恢复到正常工作状态。先从follower中选出一个新leader，其它follower从新leader处同步数据，大多数follower完成同步恢复模式就结束了。
 *  广播模式：leader处理写请求时，广播通知follower发起投票，半数以上的follower同意后，leader执行写请求（修改自身的znode），执行后将修改、更新广播给follower、observer，完成数据同步。

### leader的选举机制 ###

**zk server在集群中的4种状态**

*  LOOKING：leader宕掉了，正在选举新的leader
 *  LEADING：当前节点是leader
 *  FOLLOWING：当前节点是follower，同步leader的数据
 *  OBSERVING：当前节点是observer，同步leader的数据

**相关概念**

*  myid：唯一标识zk集群中的一个节点
 *  zxid：zookeeper transaction id，zookeeper事务id，唯一标识zk的一个写操作，可以区分数据版本。前32位表示epoch（纪元、时代），一个leader对应一个epoch（时代），换了新leader，epoch会自动使用新值；后32位表示这个时代中的事务id，即xid。
 *  Logicalclock：逻辑时钟。逻辑时钟是选举时的一个概念，其值就是zxid中epoch的值，标识一个leader的领导时代。

**leader的选举时机**

*  集群启动还没有leader时
 *  leader宕机时

**leader的选举机制、过程**

*  集群没有leader，所有zk server都处于LOOKING状态
 *  所有follower都参与投票，投的都是自己，写上自己的myid、zxid，广播出去
 *  比较zxid，先选epoch大的（纪元新的）；如果有相同的从里面选xid大的（同步数据多的）。这2项都是为了保证新leader的数据更齐全。如果还有相同的，选myid大的。
 *  选出新leader后，其它节点从新leader处同步数据，leader状态变为LEADING，follower转态变为FOLLOWING，observer状态变为OBSERVING。

### zk的节点同步流程 ###

第一次是全量同步，后续是增量同步

*  follower、observer连接到leader，并将自身的zxid发送给leader；
 *  leader根据zxid确定同步点，发送同步消息；
 *  follower、observer完成同步后通知follower，并修改自身状态为uptodate

同步期间，follower、observer不对外提供服务，同步完成、变成uptodate状态后才对外提供服务、接受client的请求。

![在这里插入图片描述][20210701203346511.png]

### zk server如何处理客户端的请求 ###

*  读请求：所有的zk server都可以处理读请求，leader收到读请求也会处理；
 *  写请求：由leader处理，follower、observer收到写请求时转交给leader处理。

leader使用paxos算法来处理写请求

*  leader将写请求都放到一个队列中，并给每个写请求分配唯一的编号，编号从小到大依次递增，按照先进先出的顺序处理，保证了事务执行的顺序一致性。
 *  执行某个写请求时，leader先执行，执行完后leader广播通知follower、observer同步这个写操作，整个流程作为一个事务来处理。如果半数以上follower、observer完成同步，就提交事务；如果在指定时间内完成同步的zk server数量没达到一半，就回滚这个写操作。
 *  follower、observer同步数据（写操作）时，会与前面已同步的写请求的编号对比，如果编号小于之前已同步的写请求的编号，说明自己数据同步出了问题，数据不一致了，立刻停止对外服务，从leader同步全量数据。

### zk的特点 ###

*  顺序一致性：zk server使用paxos算法来处理请求，将请求放在队列中，先进先出，请求的执行顺序与发送顺序一致。可用此特点实现队列
 *  数据更新原子性：一次写操作即一个事务，要么成功（都应用、同步到所有节点），要么失败（所有节点都不使用这次数据更新）
 *  单一视图: zk client无论连接到哪个zk server，读到的数据都是相同的
 *  实时性: zk client读取到的是zk server上最新的数据
 *  高性能：zk server将全量数量存储在内存中，性能极高，尤其是处理读请求的时候。处理写请求（更新znode）时，要把更新从内存同步到文件，同步到follower、observer，性能稍低

### zk的心跳机制 ###

zk通过心跳机制维护各个zk client的状态。

zk cli每隔一定时间（默认2000ms）发送一个心跳包给zk server，如果zk server连续多少次（默认10次）没有收到某个zk cli的心跳包，就认为该zk cli挂了，自动销毁对应的session、删除本次会话中创建的临时节点。

### zk的watcher机制 ###

也叫作观察/通知机制，zk client可以watch某个znode，指定的znode发生改变时，zk server会通知watch了此znode的zk client。

这其实是一种特殊的发布/订阅，zk client订阅znode的改变事件，指定的znode发生改变时zk server发布消息，订阅了该znode改变事件的zk client会收到消息。

watcher是观察者模式的体现，观察到某种现象发生时自动做一些事情。

有2种watcher

# get、stat这2种方式设置的watcher，都只监听节点本身的数据变化，不监听子孙节点
    get  -w /mall
    stat -w /mall
    
    
    # ls方式设置的watcher只监听子节点的数量变化，不监听节点本身的数据变化，也不监听孙节点
    ls -w /mall

watcher是一次性的，触发1次后就销毁，如果要继续监听，需要重新设置watcher。

### zk实现分布式通知、协调 ###

通过watcher机制实现：节点中存储需要的数据，客户端watch节点，节点数据变化时zk server自动通知对应的客户端，客户端获取更新的数据。

### acl 权限控制 ###

可以给znode设置用户权限，限制用户对znode可以进行的操作，提高数据安全性。

**znode的acl权限**

*  c：create，可创建子节点
 *  d：delete，可删除子节点
 *  r：read，可读取节点数据
 *  w：write，可写入|更新节点数据
 *  a：admin，可管理此节点，配置acl权限

**acl权限操作**

# 查看指定节点的acl权限设置，默认所有用户的权限都是cdrwa（全部权限）
    getAcl /mall
    
    # 统一设置所有用户的权限，world:anyone:权限
    setAcl world:anyone:cdrw
    
    
    # 设置某个用户的权限
    
    # auth:用户名:密码:权限
    auth:chy:abcd:cdrw
    
    # 或者 digest:用户名:BASE64(SHA1(密码)):权限
    digest:chy:BASE64(SHA1(abcd)):cdrw
    
    # auth、digest设置的密码都是以密文方式存储在zk server上，但验证密码时auth是输入明文、digest是输入SHA1加密后的密文。
    # auth更简单，digest更安全、但也更麻烦
    
    
    # 根据ip设置权限
    ip:192.168.1.1:cdrw
    
    # 给znode设置用户权限后，操作该znode时需要验证用户名、密码
    addauth digest chy:abcd

**设置超级用户**  
超级用户具有所有的acl权限，可以操作所有的znode。  
   
先在IDEA中获取密文

//用户名:密码，此处设置的用户名、密码都是super
    String str = DigestAuthenticationProvider.generateDigest("super:super");
    System.out.println(str);

编辑bin目录下的zkServer.sh

vim zkServer.sh
    
    # 找到以下代码
    nohup "$JAVA" $ZOO_DATADIR_AUTOCREATE "-Dzookeeper.log.dir=${ZOO_LOG_DIR}" \
        "-Dzookeeper.log.file=${ZOO_LOG_FILE}" "-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}" \
    
    # 在第二行末尾的\之前加上以下代码，superDigest=后面是IDEA输出的密文
    "-Dzookeeper.DigestAuthenticationProvider.superDigest=super:gG7s8t3oDEtIqF6DM9LlI/R+9Ss="

超级用户可以管理所有的znode，但如果在设置超级用户之前，就已创建了某些znode、并手动给这些znode设置了acl权限，则超级用户对这些之前创建的znode没有管理权限。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/2020053019015439.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200530204421741.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2NoeV8xODg4MzcwMTE2MQ==,size_16,color_FFFFFF,t_70
[20210701203346511.png]: https://img-blog.csdnimg.cn/20210701203346511.png