zookeeper学习笔记

zookeeper学习笔记

提供开源分布式配置服务,同步服务,命名注册
通过冗余服务实现高可用性
设计目的:将分布式一致性服务封装起来,构成高效可靠的原语集,提供简单接口
数据发布/订阅,负载均衡,命名服务,分布式协调/通知,集群管理,Master选举,分布式锁,分布式队列

数据结构
key-value式存储
名称key由/分割一系列路径元素
zookeeper中可以保存数据,集群通过在zookeeper里存取数据进行消息传递
由znode组成树,每个znode可以存放一段数据,znode下还可以挂载子节点

数据模型分类
顺序节点/普通节点
临时节点/持久节点

CAP理论
consistency一致性:数据在多个副本之间保持一致的特性
        所有节点访问同一份最新的数据副本
availability可用性:每次请求都能得到正确的响应,但不保证是最新数据
partition tolerance分区容错性:分布式系统在遇到任何网络分区故障的时候,仍然能够保证对外提供满足一致性和可用性的服务
            除非是整个网络环境都发生故障
一个分布式系统最多只能满足三项中的两项,P必须保证
zookeeper保证的是CP
spring cloud系统的注册中心eruka实现的是AP

base理论
basically avaliable基本可用:分布式系统出现故障,允许损失部分可用性
            服务降级,页面降级
soft-state软状态:允许分布式系统出现中间状态,而却中间状态不影响系统可用性
eventually consistent最终一致性:data replications数据备份节点经过一段时间达到一致性
base理论是对CAP中一致性和可用性权衡的结果:无法做到强一致,但每个应用可以根据自身特点,采用适当的方式使系统达到最终一致性

集群角色
一个leader,其他都是follower
leader可以增删改查,follower只能查询,所有更新任务会被交给leader处理.
leader批准后再发给follower执行保证一致性
由于网络不稳定,所有任务都被赋予一个唯一的顺序编号,按顺序编号执行任务,保证任务的一致性
过半投票选举机制,必须保证过半存活才能工作
myid服务器id:编号越大在选举算法中权重越大
zxid事务id:值越大数据越新,权重越大
epoch-logicalclock逻辑时钟:同一轮投票的逻辑时钟相同,每投完一次会增加
looking竞选状态
following随从状态,同步leader状态,参与投票
observing观察状态,同步leader状态,不参与投票
leading领导者状态

leader选举
每个节点启动的时候都是looking观望状态
第二台服务器启动时,两台机器互相通信,进入leader选举过程
①初始情况server1和server2都将自己作为leader服务器进行投票,投票包括推举服务器的myid,zxid,epoch,并将投票发送给集群中其他机器
②首先判断投票的有效性:是否为本轮投票(epoch),是否来自looking状态服务器
    接收的epoch>本机epoch,更新本机epoch,clear选举数据
    接受的epoch<本机epoch,将自己的选举信息发给对方
③针对每一次投票,服务器将其他服务器的投票与自己的投票进行对比
    优先比较epoch.其次检查zxid较大的服务器优先作为leader.最后比较myid较大的服务器作为leader
④统计投票,判断是否有过半机器收到相同投票信息,已经选出server2为leader服务器
⑤改变服务器状态,leader改变为leading状态,follower改变为following状态
    server3继续启动,直接加入变更自己为following
集群中leader服务器宕机或不可用时,整个集群无法对外提供服务,进入新一轮leader选举

服务端集群搭建
①准备3台zookeeper环境,下载zookeeper压缩包,配置centos环境
    echo 'export ZOOKEEPER_HOME=/export/server/zookeeper' >> /etc/profile
    echo 'export PATH=$PAHT:$ZOOKEEPER_HOME/bin' >>/etc/profile
    source /etc/profile
②创建数据目录
    mkdir /export/data/zkdata
    echo 1 >/export/data/zkdata/myid
    分别在server2,server3上执行
    echo 2 >/export/data/zkdata/myid
    echo 3 >/export/data/zkdata/myid
③修改zoo.cfg配置信息
    mv /export/server/zookeeper/conf/zoo_sample.cfg  /export/server/zookeeper/conf/zoo.cfg
    sed -i "s#^dataDir.*#dataDir=/export/data/zkdata" /export/server/zookeeper/conf/zoo.cfg
    echo 'sever.1=node:2888:3888' >>/export/server/zookeeper/conf/zoo.cfg
    echo 'sever.2=node:2888:3888' >>/export/server/zookeeper/conf/zoo.cfg
    echo 'sever.3=node:2888:3888' >>/export/server/zookeeper/conf/zoo.cfg
zookeeper三个端口号作用
2181:对client端提供服务
2888:集群内机器通信使用端口
3888:选举leader使用
按server.id=ip:port:port修改集群配置文件
根据id和对应地址分别配置myid
④启动集群
    启动前需要现关闭防火墙
    systemctl stop firewalld
    systemctl disable firewalld
    zkServer.sh start
    zkServer.sh status #查看状态
    jps #查看运行的java服务
配置免密登陆

znode状态属性
cZxid 创建节点时的事务ID
ctime 创建节点时的时间
mZxid 最后修改节点时的事务ID
mtime 最后修改节点时的时间
pZxid 子节点列表最后一次修改的事务ID,子节点内容变更不影响
cversion 子节点版本号,子节点每次修改版本号+1
dataversion 数据版本号,数据每次修改版本号+1
aclversion 权限版本号,权限每次修改版本号+1
ephemeralOwner 创建该临时节点的会话的sessionID,如果节点是持久节点,这个属性为0
dataLength 该节点的数据长度
numChildren 统计直接子节点的数量

zookeeper基础命令使用
ZooKeeper -server host:port cmd args
        stat path [watch]
        set path data [version]
        ls path [watch]
        delquota [-n|-b] path
        ls2 path [watch]
        setAcl path acl
        setquota -n|-b val path
        history 
        redo cmdno
        printwatches on|off
        delete path [version]
        sync path
        listquota path
        rmr path
        get path [watch]
        create [-s] [-e] path data acl
        addauth scheme auth
        quit 
        getAcl path
        close 
        connect host:port

session原理
基于TCP长连接,默认端口2181,即session会话
从第一次连接建立开始,客户端开始会话生命周期,客户端向服务端的ping包请求,每个会话可以设置一个超时时间
sessionID会话ID,会话的唯一标识
Timeout:会话超时时间
Tick Time:下次会话超时时间点.默认2000ms,在zoo.cfg文件中配置,便于server端对session会话实行分桶策略管理
isClosing:标记一个会话是否已经被关闭,server端检测到会话已经超时失效,则标记为'已关闭',不再处理该会话的新请求
connecting:连接中,session一旦建立就是connecting状态,时间很短
connected:已连接,连接成功后的状态
closed:已关闭,发生在session过期,一般由于网络故障客户端重连失败,服务器宕机或客户端主动断开
会话空闲超时管理:
    服务器为每一个客户端的会话都记录上一次交互后空闲的时长,及会话空闲超时的时间点
    空闲时长超时,服务端会将该会话的Sessionld从服务端清除
    所以客户端要在空闲时定时向服务端发送心跳,维护会话长连接
分桶策略: 将空闲超时时间相近的会话放到同一个桶中管理
    检查超时时只需要检查桶中剩下的会话即可,没有超时的会话已经被移出了桶

节点特性
同一级节点key名称唯一
创建节点时必须带上全路径
session关闭时临时节点清除
自动创建顺序节点
delete命令只能一层一层删除

watcher机制
客户端向服务端注册watcher,服务端处理watcher,服务端触发watcher事件,客户端回调watcher
wather事件:(常量值)
SyncConnected  None(-1) 客户端与服务器成功建立会话
        NodeCreated(1) 监听的数据节点被创建
        NodeDeleted(2) 监听的数据节点被删除
        NodeDataChanged(3) 监听的数据节点内容改变
        NodeChildrenChanged(4) 监听的数据节点子节点列表改变
Disconnected(0) None(-1) 客户端与zk断开连接
Expired(-112) None(-1) 会话失效,通常收到SessionExpiredException异常
AuthFailed None(-1) 使用错误的scheme进行权限检查,通常收到AuthFailedException异常
机制特点:
一次性触发:watcher被触发一次,zk就会从WatcherManager中删除,服务端也会删除
    不适合监听变化非常频繁的场景
异步性:watch的通知事件是从服务器发送给客户端的,不同客户端收到watch的时间可能不同
    一个客户端在看到watch事件之前是不会看到节点数据的变化的
数据监视和子节点监视:getData()和exists()设置数据监视,getChildren()设置子节点监视
        setData()会触发当前节点上设置的数据监视
        create()会触发当前节点的数剧监视和父节点的子节点监视
        delete()会触发当前节点的数据监视,父节点的子节点监视,子节点的监视

ACL权限控制
Access Control List访问控制表
细粒度的权限管理策略(UGO,user,group,others是粗粒度权限管理策略,两个维度:组与权限)
三个维度:子znode不会继承父znode的权限
通过scheme:id:permissions构成权限列表
scheme授权策略:代表采用的权限机制
    world 对所有用户不做验证
    digest 根据用户名和密码进行权限验证
    ip 根据ip地址进行权限验证
    super 超级用户可以对任意节点进行任意 *** 作,需要在打开客户端时添加系统属性-Dxxxxx
id授权对象:代表允许访问的用户
permissions用户权限:权限组合字符串
    create(c) 允许授权对象在当前节点下创建子节点
    delete(d) 允许授权对象删除当前节点
    read(r) 允许授权对象读取当前节点数据内容,及子节点列表
    write(w) 允许授权对象修改当前节点数据内容,即子节点列表
    admin(a) 允许授权对象对当前节点进行ACL相关设置
getAcl命令:获取权限信息
setAcl命令:设置权限信息
addauth命令:输入认证授权信息,注册时输入明文密码,加密保存

ZAB协议
Zookeeper Atomic Broadcast(Zookeeper原子广播协议)
Zookeeper客户端随机连接到集群中的一个节点
读请求,直接从当前节点读取数据
写请求,节点向leader提交事务,leader收到事务提交后,会广播该事务,超过半数节点写入成功,就提交该事务
消息广播:
①客户端的所有的事务请求交给leader服务器处理
②leader将事务请求转换成为事务proposal提案,分配给一个全局递增的唯一ID(zXid),每一个proposal按zXid先后排序后处理
③将proposal分发给集群中所有的follower服务器,向所有foller节点发送数据广播请求
    为每个follower分配一个单独队列,将需要广播的proposal依次放到队列中,根据FIFO策略发送信息(异步解耦)
④分发后leader服务器等待所有follower服务器反馈(ack请求)
    收到超过半数follower的ack请求后,leader会再次向所有follower发送提交commit消息,自身完成事务提交
    follower收到commit消息后,将上一条事务提交
崩溃恢复:
leader服务器失去与过半follower的联系,就进入崩溃恢复模式
①确保已经在leader上提交的事务最终被所有服务器提交
②丢弃旨在leader上提出而没有被提交的事务
选举算法:能够确保提交已经被leader提交的事务,同时丢弃已经跳过的事务
    选举zXid最大的服务器,确保新选出的leader一定具有所有已经提交的事务
数据同步:在接受新的事务请求前,leader 首先确认事务日志中的所有proposal是否已经被集群中的过半服务器commit
    等follower将所有未同步的proposal都同步并应用到内存数据中,leader才会把follower添加到follower列表中
zXid是一个64位数字,高32位代表leader周期的epoch编号,每次leader变更epoch会+1,follower只服从epoch最高的leader命令
        低32位代表单增计数器,每处理一个客户端的事务请求,计数器就+1
选出新的leader,从leader服务区去除本地事务日志中最大编号proposal的zXid,解析得到epoch编号,+1,将低32位数字归零

分布式锁
排他锁:写锁,加锁期间其他事务不能进行读和写
共享锁:读锁,枷锁期间当前事务只能对数据对象进行读取 *** 作