小型企业网站的设计与实现,广州市城市建设网站,小程序模板页,网站功防教程1 Zookeeper工作原理
1.1 Zookeeper的角色 领导者#xff08;leader#xff09;#xff0c;负责进行投票的发起和决议#xff0c;更新系统状态 学习者#xff08;learner#xff09;#xff0c;包括跟随者#xff08;follower#xff09;和观察者#xff08;obser…
1 Zookeeper工作原理
1.1 Zookeeper的角色 » 领导者leader负责进行投票的发起和决议更新系统状态 » 学习者learner包括跟随者follower和观察者observerfollower用于接受客户端请求并想客户端返回结果在选主过程中参与投票 » Observer可以接受客户端连接将写请求转发给leader但observer不参加投票过程只同步leader的状态observer的目的是为了扩展系统提高读取速度 » 客户端client请求发起方 Zookeeper的核心是原子广播这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式它们分别是恢复模式选主和广播模式同步。当服务启动或者在领导者崩溃后Zab就进入了恢复模式当领导者被选举出来且大多数Server完成了和leader的状态同步以后恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。 为了保证事务的顺序一致性zookeeper采用了递增的事务id号zxid来标识事务。所有的提议proposal都在被提出的时候加上了zxid。实现中zxid是一个64位的数字它高32位是epoch用来标识leader关系是否改变每次一个leader被选出来它都会有一个新的epoch标识当前属于那个leader的统治时期。低32位用于递增计数。 每个Server在工作过程中有三种状态
LOOKING当前Server不知道leader是谁正在搜寻LEADING当前Server即为选举出来的leaderFOLLOWINGleader已经选举出来当前Server与之同步
1.2 Zookeeper工作原理简述 Zookeeper的核心是原子广播这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式它们分别是恢复模式和广播模式。 当服务启动或者在领导者崩溃后Zab就进入了恢复模式当领导者被选举出来且大多数server端完成了和leader的状态同步以后恢复模式就结束了。 状态同步保证了leader和server具有相同的系统状态。 一旦leader已经和多数的follower进行了状态同步后他就可以开始广播消息了即进入广播状态。这时候当一个server加入zookeeper服务中它会在恢复模式下启动 发现leader并和leader进行状态同步。待到同步结束它也参与消息广播。Zookeeper服务一直维持在Broadcast状态直到leader崩溃了或者leader失去了大部分的followers支持。 广播模式需要保证proposal被按顺序处理因此zk采用了递增的事务id号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了zxid。 实现中zxid是一个64为的数字它高32位是epoch用来标识leader关系是否改变每次一个leader被选出来它都会有一个新的epoch。低32位是个递增计数。 当leader崩溃或者leader失去大多数的follower这时候zk进入恢复模式恢复模式需要重新选举出一个新的leader让所有的server都恢复到一个正确的状态。 每个Server启动以后都询问其它的Server它要投票给谁。 对于其他server的询问server每次根据自己的状态都回复自己推荐的leader的id和上一次处理事务的zxid系统启动时每个server都会推荐自己。 收到所有Server回复以后就计算出zxid最大的那个Server并将这个Server相关信息设置成下一次要投票的Server。 计算这过程中获得票数最多的的sever为获胜者如果获胜者的票数超过半数则该server被选为leader。否则继续这个过程直到leader被选举出来。 » leader就会开始等待server连接 » Follower连接leader将最大的zxid发送给leader » Leader根据follower的zxid确定同步点 » 完成同步后通知follower 已经成为uptodate状态 » Follower收到uptodate消息后又可以重新接受client的请求进行服务了
1.3 zxid Zookeeper是如何保证消息的顺序答案是通过zxid。 可以简单的把zxid理解成Zookeeper中消息的唯一ID节点之间会通过发送Proposal事务提议来进行通信、数据同步proposal中就会带上zxid和具体的数据Message。而zxid由两部分组成 epoch 可以理解成朝代或者说Leader迭代的版本每个Leader的epoch都不一样counter 计数器来一条消息就会自增 这也是唯一zxid生成算法的底层实现由于每个Leader所使用的epoch都是唯一的而不同的消息在相同的epoch中counter的值是不同的这样一来所有的proposal在Zookeeper集群中都有唯一的zxid。
1.4 数据一致性与paxos 算法 Paxos 算法是莱斯利•兰伯特英语Leslie Lamport于 1990 年提出的一种基于消息传递且具有高度容错特性的一致性算法。 分布式系统中的节点通信存在两种模型共享内存Shared memory和消息传递Messages passing。基于消息传递通信模型的分布式系统不可避免的会发生以下错误进程可能会 慢、被杀死或者重启消息可能会延迟、丢失、重复在基础 Paxos 场景中先不考虑可能 出现消息篡改即拜占庭错误Byzantine failure即虽然有可能一个消息被传递了两次但是 绝对不会出现错误的消息的情况。Paxos 算法解决的问题是在一个可能发生上述异常的分 布式系统中如何就某个值达成一致保证不论发生以上任何异常都不会破坏决议一致性。 Paxos 算法使用一个希腊故事来描述在 Paxos 中存在三种角色分别为
Proposer提议者用来发出提案 proposalAcceptor接受者可以接受或拒绝提案Learner学习者学习被选定的提案当提案被超过半数的 Acceptor 接受后为被批准 下面更精确的定义 Paxos 要解决的问题
决议(value)只有在被 proposer 提出后才能被批准在一次 Paxos 算法的执行实例中只批准(chose)一个 valuelearner 只能获得被批准(chosen)的 value ZooKeeper 的选举算法有两种一种是基于 Basic PaxosGoogle Chubby 采用实现的另外 一种是基于 Fast PaxosZooKeeper 采用算法实现的。系统默认的选举算法为 Fast Paxos。 并且 ZooKeeper 在 3.4.0 版本后只保留了 FastLeaderElection 算法。 ZooKeeper 的核心是原子广播这个机制保证了各个 Server 之间的同步。实现这个机制的协 议叫做 ZAB 协议Zookeeper Atomic BrodCast。 ZAB 协议有两种模式它们分别是崩溃恢复模式选主和原子广播模式同步。 1、当服务启动或者在领导者崩溃后ZAB 就进入了恢复模式当领导者被选举出来且大 多数 Server 完成了和 leader 的状态同步以后恢复模式就结束了。状态同步保证了 leader 和 follower 之间具有相同的系统状态。 2、当 ZooKeeper 集群选举出 leader 同步完状态退出恢复模式之后便进入了原子广播模式。 所有的写请求都被转发给 leader再由 leader 将更新 proposal 广播给 follower 为了保证事务的顺序一致性zookeeper 采用了递增的事务 id 号zxid来标识事务。所有 的提议proposal都在被提出的时候加上了 zxid。实现中 zxid 是一个 64 位的数字它高 32 位是 epoch 用来标识 leader 关系是否改变每次一个 leader 被选出来它都会有一个新 的 epoch标识当前属于那个 leader 的统治时期。低 32 位用于递增计数。 这里给大家介绍以下 Basic Paxos 流程
1、选举线程由当前 Server 发起选举的线程担任其主要功能是对投票结果进行统计并选 出推荐的 Server2、选举线程首先向所有 Server 发起一次询问(包括自己)3、选举线程收到回复后验证是否是自己发起的询问(验证 zxid 是否一致)然后获取对方 的 serverid(myid)并存储到当前询问对象列表中最后获取对方提议的 leader 相关信息 (serverid,zxid)并将这些信息存储到当次选举的投票记录表中4、收到所有 Server 回复以后就计算出 id 最大的那个 Server并将这个 Server 相关信息设 置成下一次要投票的 Server5、线程将当前 id 最大的 Server 设置为当前 Server 要推荐的 Leader如果此时获胜的 Server 获得 n/2 1 的 Server 票数 设置当前推荐的 leader 为获胜的 Server将根据获胜的 Server 相关信息设置自己的状态否则继续这个过程直到 leader 被选举出来。 通过流程分析我们可以得出要使 Leader 获得多数 Server 的支持则 Server 总数必须是奇 数 2n1且存活的 Server 的数目不得少于 n1。 每个 Server 启动后都会重复以上流程。在恢复模式下如果是刚从崩溃状态恢复的或者刚 启动的 server 还会从磁盘快照中恢复数据和会话信息zk 会记录事务日志并定期进行快照 方便在恢复时进行状态恢复。 Fast Paxos 流程是在选举过程中某 Server 首先向所有 Server 提议自己要成为 leader当其 它 Server 收到提议以后解决 epoch 和 zxid 的冲突并接受对方的提议然后向对方发送 接受提议完成的消息重复这个流程最后一定能选举出 Leader
1.5 Observer • Zookeeper需保证高可用和强一致性 • 为了支持更多的客户端需要增加更多Server • Server增多投票阶段延迟增大影响性能 • 权衡伸缩性和高吞吐率引入Observer • Observer不参与投票 • Observers接受客户端的连接并将写请求转发给leader节点 • 加入更多Observer节点提高伸缩性同时不影响吞吐率
1.6 Zookeeper 的节点
1.6.1 节点有哪些类型
Znode两种类型
持久的persistent客户端和服务器端断开连接后创建的节点不删除默认。短暂的ephemeral客户端和服务器端断开连接后创建的节点自己删除。
Znode有四种目录节点形式
持久化目录节点PERSISTENT客户端与Zookeeper断开连接后该节点依旧存在持久化顺序编号目录节点PERSISTENT_SEQUENTIAL客户端与Zookeeper断开连接后该节点依旧存在只是Zookeeper给该节点名称进行顺序编号临时目录节点EPHEMERAL客户端与Zookeeper断开连接后该节点被删除临时顺序编号目录节点EPHEMERAL_SEQUENTIAL客户端与Zookeeper断开连接后该节点被删除只是Zookeeper给该节点名称进行顺序编号
「注意」创建ZNode时设置顺序标识ZNode名称后会附加一个值顺序号是一个单调递增的计数器由父节点维护。
1.6.2 节点属性有哪些 一个znode节点不仅可以存储数据还有一些其他特别的属性。接下来我们创建一个/test节点分析一下它各个属性的含义。
[zk: localhost:2181(CONNECTED) 6] get /test 456 cZxid 0x59ac // ctime Mon Mar 30 15:20:08 CST 2020 mZxid 0x59ad mtime Mon Mar 30 15:22:25 CST 2020 pZxid 0x59ac cversion 0 dataVersion 2 aclVersion 0 ephemeralOwner 0x0 dataLength 3 numChildren 0 复制代码
属性说明 1.7 Zookeeper 的数据模型 » 层次化的目录结构命名符合常规文件系统规范 » 每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识 » 节点Znode可以包含数据和子节点但是EPHEMERAL类型的节点不能有子节点 » Znode中的数据可以有多个版本比如某一个路径下存有多个数据版本那么查询这个路径下的数据就需要带上版本 » 客户端应用可以在节点上设置监视器 » 节点不支持部分读写而是一次性完整读写
1.8 Zookeeper leader 选举
1.8.1 Leader选举概述 Leader选举是保证分布式数据一致性的关键所在。当Zookeeper集群中的一台服务器出现以下两种情况之一时需要进入Leader选举。
(1) 服务器初始化启动。
(2) 服务器运行期间无法和Leader保持连接。 下面就两种情况进行分析讲解。
1.8.2 服务器启动时期的Leader选举 若进行Leader选举则至少需要两台机器这里选取3台机器组成的服务器集群为例。在集群初始化阶段当有一台服务器Server1启动时其单独无法进行和完成Leader选举当第二台服务器Server2启动时此时两台机器可以相互通信每台机器都试图找到Leader于是进入Leader选举过程。选举过程如下
(1) 每个Server发出一个投票。由于是初始情况Server1和Server2都会将自己作为Leader服务器来进行投票每次投票会包含所推举的服务器的myid和ZXID使用(myid, ZXID)来表示此时Server1的投票为(1, 0)Server2的投票为(2, 0)然后各自将这个投票发给集群中其他机器。
(2) 接受来自各个服务器的投票。集群的每个服务器收到投票后首先判断该投票的有效性如检查是否是本轮投票、是否来自LOOKING状态的服务器。
(3) 处理投票。针对每一个投票服务器都需要将别人的投票和自己的投票进行PKPK规则如下
优先检查ZXID。ZXID比较大的服务器优先作为Leader。如果ZXID相同那么就比较myid。myid较大的服务器作为Leader服务器。 对于Server1而言它的投票是(1, 0)接收Server2的投票为(2, 0)首先会比较两者的ZXID均为0再比较myid此时Server2的myid最大于是更新自己的投票为(2, 0)然后重新投票对于Server2而言其无须更新自己的投票只是再次向集群中所有机器发出上一次投票信息即可。
(4) 统计投票。每次投票后服务器都会统计投票信息判断是否已经有过半机器接受到相同的投票信息对于Server1、Server2而言都统计出集群中已经有两台机器接受了(2, 0)的投票信息此时便认为已经选出了Leader。
(5) 改变服务器状态。一旦确定了Leader每个服务器就会更新自己的状态如果是Follower那么就变更为FOLLOWING如果是Leader就变更为LEADING。
1.8.3 服务器运行时期的Leader选举 在Zookeeper运行期间Leader与非Leader服务器各司其职即便当有非Leader服务器宕机或新加入此时也不会影响Leader但是一旦Leader服务器挂了那么整个集群将暂停对外服务进入新一轮Leader选举其过程和启动时期的Leader选举过程基本一致。假设正在运行的有Server1、Server2、Server3三台服务器当前Leader是Server2若某一时刻Leader挂了此时便开始Leader选举。选举过程如下
(1) 变更状态。Leader挂后余下的非Observer服务器都会讲自己的服务器状态变更为LOOKING然后开始进入Leader选举过程。
(2) 每个Server会发出一个投票。在运行期间每个服务器上的ZXID可能不同此时假定Server1的ZXID为123Server3的ZXID为122在第一轮投票中Server1和Server3都会投自己产生投票(1, 123)(3, 122)然后各自将投票发送给集群中所有机器。
(3) 接收来自各个服务器的投票。与启动时过程相同。
(4) 处理投票。与启动时过程相同此时Server1将会成为Leader。
(5) 统计投票。与启动时过程相同。
(6) 改变服务器的状态。与启动时过程相同。 1.9 Zookeeper 的读写机制
1.9.1 读写流程 下图就是集群模式下一个Zookeeper Server节点提供读写服务的一个流程。 如上图所示每个Zookeeper Server节点除了包含一个请求处理器来处理请求以外都会有一个内存数据库(ReplicatedDatabase)用于持久化数据。ReplicatedDatabase 包含了整个Data Tree。 来自于Client的读服务Read Requst是直接由对应Server的本地副本来进行服务的。 至于来自于Client的写服务Write Requst因为Zookeeper要保证每台Server的本地副本是一致的单一系统映像需要通过一致性协议后文提到的ZAB协议来处理成功处理的写请求数据更新会先序列化到每个Server节点的本地磁盘为了再次启动的数据恢复再保存到内存数据库中。 集群模式下Zookeeper使用简单的同步策略通过以下三条基本保证来实现数据的一致性
全局串行化所有的写操作 串行化可以把变量包括对象,转化成连续bytes数据. 你可以将串行化后的变量存在一个文件里或在网络上传输. 然后再反串行化还原为原来的数据。
保证同一客户端的指令被FIFO执行以及消息通知的FIFO
FIFO -先入先出
自定义的原子性消息协议 简单来说对数据的写请求都会被转发到Leader节点来处理Leader节点会对这次的更新发起投票并且发送提议消息给集群中的其他节点当半数以上的Follower节点将本次修改持久化之后Leader 节点会认为这次写请求处理成功了提交本次的事务。
1.9.2 乐观锁 Zookeeper 的核心思想就是提供一个非锁机制的Wait Free 的用于分布式系统同步的核心服务。其核心对于文件、数据的读写服务并不提供加锁互斥的服务。 但是由于Zookeeper的每次更新操作都会更新ZNode的版本详见第一章也就是客户端可以自己基于版本的对比来实现更新数据时的加锁逻辑。例如下图。 就像我们更新数据库时会新增一个version字段通过更新前后的版本对比来实现乐观锁。
1.10 Zookeeper节点数据操作流程 在Client向Follwer发出一个写的请求Follwer把请求发送给LeaderLeader接收到以后开始发起投票并通知Follwer进行投票Follwer把投票结果发送给LeaderLeader将结果汇总后如果需要写入则开始写入同时把写入操作通知给 Leader然后commit;Follwer把请求结果返回给Client
1.10.1 Follower主要有四个功能
向Leader发送请求PING消息、REQUEST消息、ACK消息、REVALIDATE消息接收Leader消息并进行处理接收Client的请求如果为写请求发送给Leader进行投票返回Client结果。
1.10.2 Leader消息类型 Follower的消息循环处理如下几种来自Leader的消息
PING消息心跳消息PROPOSAL消息Leader发起的提案要求Follower投票COMMIT消息服务器端最新一次提案的信息UPTODATE消息表明同步完成REVALIDATE消息根据Leader的REVALIDATE结果关闭待revalidate的 session还是允许其接受消息SYNC消息返回SYNC结果到客户端这个消息最初由客户端发起用来强制得到最新的更新。
1.11 为什么zookeeper集群的数目一般为奇数个 •Leader选举算法采用了Paxos协议 •Paxos核心思想当多数Server写成功则任务数据写成功如果有3个Server则两个写成功即可如果有4或5个Server则三个写成功即可。 •Server数目一般为奇数3、5、7如果有3个Server则最多允许1个Server挂掉如果有4个Server则同样最多允许1个Server挂掉由此 我们看出3台服务器和4台服务器的的容灾能力是一样的所以为了节省服务器资源一般我们采用奇数个数作为服务器部署个数。 参考链接
ZooKeeper学习之路 八ZooKeeper原理解析
Zookeeper系列二分布式架构详解、分布式技术详解、分布式事务
随笔分类 - Zookeeper专题系列
Zookeeper简介及核心概念_Cynicism_Kevin的博客-CSDN博客
zookeeper安装以及使用_燕少༒江湖的博客-CSDN博客
Zookeeper工作原理详细_zookeeper原理_笔墨登场说说的博客-CSDN博客
Zookeeper的功能以及工作原理_zookeeper的主要功能_空白格的空白的博客-CSDN博客
ZooKeeper基本原理
深入了解Zookeeper核心原理
Zookeeper原理解析 - 简书
zookeeper的领导者选举和原子广播 - lpshou - 博客园
Zookeeper原理详解_百里度的博客-CSDN博客
Zookeeper学习系列【三】Zookeeper 集群架构、读写机制以及一致性原理(ZAB协议) - 掘金
从背景到原理到架构体系粉碎Zookeeper面试连环炮 - 掘金
