红泥小火炉


Zookeeper

Nathaniel 2021-12-09 1010浏览 0条评论
首页/正文
分享到: / / / /

Zookeeper基础

简介

开源的分布式应用程序协调服务器,为分布式系统提供一致性服务。主要特性:顺序一致(写请求顺序),原子性操作,单一视图,可靠,保证最终一致性。

算法基础

Paxos算法

目的:解决在分布式系统中如何就某项决议达成一致。

前提:不存在拜占庭将军问题(信道是安全可靠的,消息在传递过程中不会被修改)

角色:Proposer:提案者,Acceptor:表决者,Learner:同步者

描述:整个流程分为准备阶段(prepare)和接受阶段(accept);

准备阶段

​ 提案者(Proposer)提交一个编号为N的提案,向所有的表决者(Acceptor)发送prepare(N)请求,试探集群是否支持该提案;

​ 表决者(Acceptor)接收到其他主机发送过来的prepare(N),会比较N与曾经accept过的提案中的最大编号maxN:

​ 如果N小于maxN,说明该提案已过时,表决者不回应或者回应Error的方式拒绝该提案;

​ 如果N大于maxN,说明该提案可以接受,表决者会将N记下,并且反馈给提案者响应Proposal(id,maxN,value),此处的value是曾经接受过提案的最大编号对应的value。

接受阶段

​ 提案者(Proposer)收到超过半数的表决者(Acceptor)的反馈,会发送真实的提案Proposal(id,N,value)给所有的表决者;

​ 表决者(Acceptor)收到提案之后,会再次比较N和maxN(此时的maxN可能已经发生了变化);

​ 如果N大于等于maxN,则当前表决者接受该提案,并反馈给提案者;

​ 如果N小于maxN,则当前表决者不回应或者回应Error的方式来拒绝该提案。

同步数据

​ 提案者收到的反馈数量超过半数,则广播两类消息:

​ 向接受该提案的表决者发送可执行数据同步信号,使其执行接受到的提案。

​ 向未发送接受反馈的表决者发送提案+可执行数据同步信号,使其接受提案并执行。

问题:活锁问题

以两个提案者A,B的提案过程为例,A提交了编号为A1的提案,并收到过半数的表决者响应,在A准备进入接受阶段之前,B提交了编号为B1的提案,此时的B1>A1,那么也会正常通过过半数的表决者响应,也通过了准备阶段,此时A进入接受阶段,会导致当前的提案A1失效,A会再次发起A2的提案,此时A2>B1,这样的提案会导致B中B1提案无法被接受,B再次发起B2的提案,B2>A2,这样会陷入无限循环,导致无法有提案被接受。

ZAB协议

Zookeeper原子消息广播协议,是为Zookeeper设计的支持崩溃恢复的原子广播协议,是Zookeeper实现分布式数据一致性的基础。

核心:定义了对于那些改变Zookeeper服务器数据状态的事务请求的处理方式。

3334

  • 三类角色
    • Leader:写请求的唯一处理者;
    • Follower:可以直接处理读请求,不处理写请求,可以对Leader发起的提案进行表决,可以选举或者被选举为Leader;
    • Observer:只处理读请求,不对提案进行表决,不参与Leader选举。
  • 三个数据
    • zxid:64位数据,高32位标识epoch,低32位标识xid;
    • epoch:每个Leader选举之后会产生一个新的epoch;
    • xid:事务id
  • 三种模式
    • 恢复模式:集群启动或者Leader崩溃之后会触发,包含:Leader选举,初始化同步。
    • 广播模式:初始化广播和更新广播
    • 同步模式:初始化同步和更新同步
  • 四种状态
    • LOOKING:选举状态
    • FOLLOWING:Follower的正常工作状态
    • OBSERVING:Observer的正常工作状态
    • LEADING:Leader的正常工作状态

描述

  • Leader选举

    分为两个时间点:集群启动和Leader宕机

    集群启动:

    A节点发起投票(myid,zxid),myid标识集群节点,投票内容假设为(1,0),当前没有其他节点,A的状态为LOOKING;
    B节点启动之后,也会发起投票,假设为(2,0);AB两节点都会收到对方的投票信息,会首先比较zxid,优先选择zxid大的节点为Leader;此时zxid相同,则比较myid,选择myid大的节点为Leader,所以A节点接受B节点的投票(2,0);
    B节点的投票已经超过半数,则B为Leader,状态变更为LEADING,A节点状态变更为FOLLOWING;
    C节点启动之后,发现集群状态不是LOOKING,则直接变更状态为FOLLOWING。
    

    Leader宕机:

    各个Follower变更状态为LOOKING;
    各自投票,类似于启动过程中的投票过程,只是此时zxid不再为0,可能A的投票为(1,100),C的投票为(3,90),优先选择zxid大的节点的投票,此时C节点接受A节点的投票;
    A节点的投票已经超过半数,则A为Leader,状态变更为LEADING,C节点状态变更为FOLLOWING。
    
  • 初始化同步

    Leader选举完成后触发。

    Leader为每一个Learner(Follower+Observer)建立一个队列;
    将未同步的事务封装为提案(Proposal);
    将提案发送给各个Learner,Learner收到之后执行该提案中的事务;
    Learner执行成功之后反馈给Leader;
    Leader将发起反馈的Follower加入到Follower队列。
    
  • 消息广播

    Leader收到写请求之后,会将写请求封装成提案;
    Leader将提案发送给Follower列表中的Follower;Follower收到提案之后会比较本地的zxid和提案中的zxid,并反馈给Leader;
    Leader收到过半的反馈之后,会发送commit消息给Follower,给Observer发送提案,Observer收到提案之后直接提交执行。
    

CAP理论

一个分布式系统不能同时满足一致性,可用性,分区容错性这三个基本需求,最多只能同时满足其中两项。在分布式系统中,分区容错性是必须要保证的,所以在分布式环境下,只能保证一致性(CP)或者可用性(AP),Zookeeper遵循了CP原则。

BASE理论

BASE是基本可用(Basically Available)、软状态(Soft state)和最终一致性(Eventually consistent)短语的缩写,是CAP定理对一致性和可用性权衡的结果。

核心思想是即使无法做到强一致性,但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性。

  • 基本可用:系统在出现故障时,允许损失部分可用性。主要体现在响应时间和功能的损失。
  • 软状态:允许系统在不同节点上的数据副本在进行数据同步的过程中存在延时。
  • 最终一致性:系统需要保证最终数据能达到一致,而不需要实时保证系统数据的强一致性。
    • 因果一致性:存在前后操作同一数据的两个进程中,后序进程的操作只能基于前序进程的操作结果。
    • 读已之所写:当前进程总能读到自己操作过的最新数据。
    • 会话一致性:在同一个会话中总能读到数据项的最新值。
    • 单调读一致性:进程中的数据访问是存在顺序的,不会存在后序访问到前序访问的旧值。
    • 单调写一致性:同一个进程的写操作被顺序执行。

Zookeeper进阶

数据模型znode

类型:

  • 持久节点:节点状态中ephemeralOwner为0。
create /path value
  • 持久顺序节点
create -s /path value
  • 临时节点:节点状态中ephemeralOwner为当前会话的会话id。
create -e /path/ value
  • 临时顺序节点
create -e -s /path value

会话

会话状态:CONNECTING-连接中,CONNECTED-已连接,CLOSE-已关闭

会话空闲超时管理-服务端维护

​ 服务端记录了客户端上一次会话交互之后的空闲时长,以及会话空闲超时的时间点。

​ 服务端通过空闲超时管理来判断会话是否发生中断。

​ 策略:分桶,将空闲超时时间相近的会话放入一个桶中,只需要检测桶中是否还有会话,如果有会话,那么这些会话肯定都是超时的会话。

Watcher机制

类似与websocket,允许事件注册及事件回调。

客户端生成watcher对象,并将该对象存储在watcherManager中;
客户端向服务端注册watcher事件;
当对应的事件发生之后,服务端会向客户端发送事件通知;
客户端收到事件通知之后,从watcherManager中找到对应的watcher对象,由watcher对象执行相关的回调逻辑。

权限控制-ACL

维度:授权策略Schema,授权对象id,用户权限permission,父子节点之间不会存在权限继承。

授权策略和授权对象均有四种方式

  • IP:根据ip地址进行校验和授权
  • digest:根据用户名/密码校验和授权
  • world:对所有用户不做校验,授权对象只有一个,anyone
  • super:超级权限,授权对象同digest

用户权限:C(创建子节点),D(删除当前节点),R(读取数据内容及子节点列表),W(修改数据内容及子节点列表),A(授权权限)

最后修改:2021-12-09 22:10:25 © 著作权归作者所有
上一篇

评论列表

还没有人评论哦~赶快抢占沙发吧~