zookeeper 的原理及集群选主

素颜马尾好姑娘i 2023-06-28 06:08 10阅读 0赞

### zookeeper 的原理 及 集群选主 ###

*   *   *  zookeeper的典型应用场景：
         *   *  配置文件管理：
             *  集群管理：
             *  锁管理：
             *  队列管理：
             *  命名服务：
         *  zookeeper的应用：
         *  zookeeper中的角色：
         *   *  leader
             *  follower
             *  observer
         *  详解stat信息：
         *  集群选主
         *   *  全新集群选主：
             *  非全新集群选主：
         *  数据同步过程：
         *  写数据过程：

### zookeeper的典型应用场景： ###

`
    配置文件管理
    集群管理
    锁管理
    队列管理
    `

#### 配置文件管理： ####

场景：3台机器，都有公共的配置文件， 在config目录下，3台机器如何保证配置文件的一致性？
    使用：监听器+文件系统

#### 集群管理： ####

1）集群选主
    	hbase 选主机制，过半选举
    2）节点的上下线
    	目前的hadoop集群中，namenode 识别datanode宕机，需要630s 的时间，还是挺长的。
    	如果有zookeeper的话，基本可以实时监控是否宕机

#### 锁管理： ####

读锁：
    	共享锁，实际上创建的是 临时有编号节点
    写锁：
    	排它锁，实际上创建的是 临时无编号节点

#### 队列管理： ####

fifo： 先进先出
    案例：抢购   实际上创建的是 临时有编号节点

#### 命名服务： ####

一个节点的命名修改，其它节点可以迅速修改。（分布式，全局统一命名）

### zookeeper的应用： ###

1）选主机制
    	2）利用监听器监听文件系统

### zookeeper中的角色： ###

#### leader ####

leader :
    	发起提议
    	接受客户端的读写请求  主要处理写请求
    	具有选举权 和 被选举权
    	时刻具备最新数据

#### follower ####

follower
    	接受客户端的读写请求  读请求可以自己处理  如果接受到客户端的写请求  将写请求转发给leader 
    	具备选举权  和 被选举权

#### observer ####

observer 
    	配置方式：  server.4=hadoop04:2888:3888：observer
    	不具备选举权 和被选举权  的 follower 
    	作用：分担集群的读数据的压力  接受到写请求  转发leader 
    	95%读  5%写

整个写入数据过程中， leader最先写入， follower|observer 从leader进行数据同步。  
如果follower|observer 数据更新过程中， leader宕机了， 则重新选主。  
选主参考依据： 数据完整度

### 详解stat信息： ###

cZxid = 0x200000075
    ctime = Mon Aug 05 23:52:15 CST 2019  节点创建时间
    mZxid = 0x200000075
    mtime = Mon Aug 05 23:52:15 CST 2019  节点修改时间
    pZxid = 0x20000007e
    cversion = 6  创建版本
    dataVersion = 0  数据版本
    aclVersion = 0  权限版本
    ephemeralOwner = 0x0  节点的生命周期标识
    	永久节点   0x0 
    	ephemeralOwner = 0x16c5d8f0a950009  临时节点 
    	sessionid = 0x16c5d8f0a950009   
    dataLength = 0   数据长度
    numChildren = 6  子节点个数
    
    数据版本id 数据版本越大   数据越新  全局的
    cZxid  创建节点事件id 
    	创建节点  +1 
    mZxid  修改节点事件id 
    	修改节点内容 发生变化
    pZxid	子节点变化的事件id 
    	创建一个节点的子节点的时候   发生变化
    	
    cZxid   mZxid  pZxid  整体无论修改了哪一个  都会全局顺序递增
    上面的3个id 共同标识  整个集群中的这个机器  数据更新程度
    只要zxid 最大  这个机器中的数据最新的

### 集群选主 ###

#### 全新集群选主： ####

依据 id 和启动顺序。

当集群启动数量不到一半的时候：没有leader
    
    当集群启动数量超过一半的时候，选取id比价大的为leader，其余为follower

#### 非全新集群选主： ####

集群运行一段时间之后,如果leader宕机，则集群重新选主。
    依据：
    	1）myid 
    	2）zxid 
    	3）逻辑时钟  投票的轮数
    
    选举规则：
    1）先根据逻辑时钟，如果逻辑时钟不统一，先统一逻辑时钟。
    2）统一完成逻辑时钟之后，按照zxid进行选择，  zxid大的胜出。
    3）在zxid大的里面选myid， myid大的胜出
    最终选的leader，数据版本是最新的。

### 数据同步过程： ###

选举新的leader之后，follower|observer 的数据需要和leader的数据保持一致。这就需要数据同步。数据同步过程如下：

1、leader 等待 follower|observer 连接；
    	2、follower|observer 连接 leader，将最大的 zxid 发送给 leader；
    	3、leader 根据 follower 的 zxid 确定是否需要更新数据，如果follwer的   zxid < leader 的zxid，则需要数据同步，确定数据更新同步点；
    	4、follower 进行数据更新，follower 将自己的状态切换为 update 状态，不再接受客户端的读数据请求；
    	5、follower更新完成数据，将自己的状态改为updated ，又可以重新接受 client 的请求进行服务了。
    	
    	
    	follwer   zxid == leader zxid  不需要更新数据
    	follwer   zxid < leader zxid   需要更新数据
    	需要更新的数据范围为：	follwer zixd + 1  ---> leader zxid

注意：zookeeper节点在进行数据同步的过程中，是不对外提供服务的。

### 写数据过程： ###

1）客户端写入zk数据时候 请求最终被leader进行处理
    2）leader进行数据写入。 
    3）leader写入数据成功，不代表数据真的写入成功。  follower | observer 进行数据同步，同上面。
    4）当过半的follower更新数据成功，   leader才将这条数据标记为真正的可读数据， 剩下的机器自己慢慢更新。