zookeeper01-基本概念原理

Zookeeper

概念

zk是开源的具有高可用、高性能、具有分布式的数据一致性,为分布式应用提供服务的数据管理及协调apache项目。

工作机制

image-20210419093142086

客户端是观察者订阅特定被观察者节点状态的程序

特点

image-20210419101850384

  • 如果更新数据的时候有一个节点挂了其他的依然能更新
  • 等节点复活后会同步数据
  • 所有的请求都由Leader处理
  • 由于更新时顺序进行的,所谓实时性是在请求被处理才能读到最新数据

核心功能

  • 数据发布订阅
  • 负载均衡
  • 命名服务
  • 分布式协调/通信
  • 集群管理
  • Master选举
  • 分布式锁
  • 分布式队列

数据发布和订阅(配置中心)image-20210419111707943

  • 发布/订阅一般有两种设计模式:推模式和拉模式,服务端主动将数据更新发送给所有订阅的客户端称为推模式;客户端主动请求获取最新数据称为拉模式,Zookeeper采用了推拉相结合的模式,客户端向服务端注册自己需要关注的节点,一旦该节点数据发生变更,那么服务端就会向相应的客户端推送Watcher事件通知,客户端接收到此通知后,主动到服务端获取最新的数据。
  • 若将配置信息存放到Zookeeper上进行集中管理,在通常情况下,应用在启动时会主动到Zookeeper服务端上进行一次配置信息的获取,同时,在指定节点上注册一个Watcher监听,这样在配置信息发生变更,服务端都会实时通知所有订阅的客户端,从而达到实时获取最新配置的目的。
  • 程序总是需要配置的,如果程序分散部署在多台机器上,要逐个改变配置就变得困难。好吧,现在把这些配置全部放到zookeeper上去,保存在 Zookeeper 的某个目录节点中,然后所有相关应用程序对这个目录节点进行监听,一旦配置信息发生变化,每个应用程序就会收到 Zookeeper 的通知,然后从 Zookeeper 获取新的配置信息应用到系统中就好。

负载均衡

image-20210419104714849

  • 分布式系统为了保证可用性,通常通过副本的方式来对数据和服务进行部署,而对于客户端吧来说,只需要在这样对等的服务提供方式中选择一个来执行相关的业务逻辑,以达到优化资源使用、最大化吞吐率、最小化响应时间和避免过载的目的。怎么选,这就是负载均衡的应用。
  • zk实现负载均衡就是通过watcher机制和临时节点判断哪些节点宕机来获得可用的节点实现的:

命名服务

image-20210419122746371

集群管理image-20210419112715025

  • 所谓集群管理无在乎两点:是否有机器退出和加入、选举master。

    ​ 对于第一点,所有机器约定在父目录GroupMemgers下创建临时目录节点,然后监听父目录节点的子节点变化消息。一旦有机器挂掉,该机器与 zookeeper的连接断开,其所创建的临时目录节点被删除,所有其他机器都收到通知:某个兄弟目录被删除,于是,所有人都知道:它上船了。新机器加入 也是类似,所有机器收到通知:新兄弟目录加入,highcount又有了。

    ​ 对于第二点,我们稍微改变一下,所有机器创建临时顺序编号目录节点,每次选取编号最小的机器作为master就好。

分布式锁

img

  • 有了zookeeper的一致性文件系统,锁的问题变得容易。锁服务可以分为两类,一个是保持独占,另一个是控制时序。
  • 对于第一类,我们将zookeeper上的一个znode看作是一把锁,通过createznode的方式来实现。所有客户端都去创建 /distribute_lock 节点,最终成功创建的那个客户端也即拥有了这把锁。厕所有言:来也冲冲,去也冲冲,用完删除掉自己创建的distribute_lock 节点就释放出锁。
  • 对于第二类, /distribute_lock 已经预先存在,所有客户端在它下面创建临时顺序编号目录节点,和选master一样,编号最小的获得锁,用完删除,依次方便。

stat结构体

(1)czxid-创建节点的事务zxid

每次修改ZooKeeper状态都会收到一个zxid形式的时间戳,也就是ZooKeeper事务ID。

事务ID是ZooKeeper中所有修改总的次序。每个修改都有唯一的zxid,如果zxid1小于zxid2,那么zxid1在zxid2之前发生。

2)ctime - znode被创建的毫秒数(从1970年开始

(3)mzxid - znode最后更新的事务zxid

(4)mtime - znode最后修改的毫秒数(从1970年开始)

(5)pZxid-znode最后更新的子节点zxid

(6)cversion - znode子节点变化号,znode子节点修改次数

(7)dataversion - znode数据变化号

(8)aclVersion - znode访问控制列表的变化号

(9)ephemeralOwner- 如果是临时节点,这个是znode拥有者的session id。如果不是临时节点则是0。

(10)dataLength- znode的数据长度

(11)numChildren - znode子节点数量

监听器原理

  • socket通信
  • 创建两个线程,一个listener,一个connect
  • 通过connect线程将注册监听事件发送给zookeeper集群的监听列表中。
  • 被监听对象发生变化,则将事件发送给listenerpeocess

选举机制

  • 半数以上节点存活则集群存活
  • 按启动顺序开始投票
  • 先给自己投票
  • 交换投票信息
  • 先比较zxid若相同再比较myid,小的把自己的票投给大的

写数据流程

image-20210420094912681

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Zookeeper是一个分布式协调服务,而Paxos算法是Zookeeper用来实现分布式一致性的核心算法之一。Paxos算法的主要目的是在一个分布式系统中达成一致性,保证多台机器之间的数据一致性。下面是Paxos算法的原理及过程: 1. 基本概念: - Proposer:提出提案的角色,向Acceptor发送提案。 - Acceptor:接收提案的角色,可以接收多个Proposer的提案,并对提案进行投票。 - Learner:观察者角色,只能观察到接收到的提案,不能进行投票。 2. 运行过程: - 阶段1:Proposer向多个Acceptor发送编号为n的提案,请求Acceptor投票。如果Acceptor还没有接受过提案,就接受这个提案,否则拒绝这个提案。 - 阶段2:如果Proposer收到了多数Acceptor的回应,就会发送编号为n的提案给多数Acceptor,请求它们接受这个提案。当一个Acceptor接受提案后,就会发送一个回应给Proposer,提案被接受。 - 阶段3:如果Proposer收到了多数Acceptor的回应,就会将这个提案标记为已提交,然后通知Learner。Learner接收到这个提案后,就知道了这个提案已经被提交了。 3. 原理解释: - 在阶段1中,Proposer发送的提案是编号为n的提案,表示这个提案是第n次提出的。如果Acceptor还没有接受过提案,就接受这个提案,并且会把自己的编号告诉Proposer,以便Proposer知道多数Acceptor的编号。 - 在阶段2中,Proposer会向多数Acceptor发送编号为n的提案,请求它们接受这个提案。如果多数Acceptor接受这个提案,就代表这个提案已经被多数节点接受,达成了一致性。 - 在阶段3中,Proposer会将这个提案标记为已提交,并通知Learner。Learner接收到这个提案后,就知道了这个提案已经被提交了。 总之,Paxos算法通过投票的方式来达成一致性,同时也保证了分布式系统的可靠性和容错性。在Zookeeper中,通过Paxos算法实现分布式一致性,可以用于解决分布式锁、分布式队列等问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值