广州智能建站软件,广东省广州市白云区人和镇,一个服务器多个网站好吗,网站建设个人网银1、概念介绍
ZooKeeper 是一个开放源码的分布式应用程序协调服务#xff0c;为分布式应用提供一致性服务的软件#xff0c;由雅虎创建#xff0c;是 Google Chubby 的开源实现#xff0c;是 Apache 的子项目#xff0c;之前是 Hadoop 项目的一部分#xff0c;使用 Java …1、概念介绍
ZooKeeper 是一个开放源码的分布式应用程序协调服务为分布式应用提供一致性服务的软件由雅虎创建是 Google Chubby 的开源实现是 Apache 的子项目之前是 Hadoop 项目的一部分使用 Java 实现。
ZooKeeper 是一个典型的分布式数据一致性解决方案分布式应用程序可以基于ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。
ZooKeeper 最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心服务注册与发现中心。服务生产者将自己提供的服务注册到 ZooKeeper 中心服务的消费者在进行服务调用的时候先到 ZooKeeper 中查找服务获取到服务生产者的详细信息之后再去调用服务生产者的内容与数据。
ZooKeeper 的由来 Zookeeper 最早起源于雅虎研究院的一个研究小组。在当时研究人员发现在雅虎内部很多大型系统基本都需要依赖一个类似的系统来进行分布式协调但是这些系统往往都存在分布式单点问题。所以雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架以便让开发人员将精力集中在处理业务逻辑上。
关于“ZooKeeper”这个项目的名字其实也有一段趣闻。在立项初期考虑到之前内部很多项目都是使用动物的名字来命名的例如著名的 Pig 项目)雅虎的工程师希望给这个项目也取一个动物的名字。时任研究院的首席科学家 Raghu Ramakrishnan 开玩笑地说“在这样下去我们这儿就变成动物园了”
此话一出大家纷纷表示就叫动物园管理员吧因为各个以动物命名的分布式组件放在一起雅虎的整个分布式系统看上去就像一个大型的动物园了。 而 Zookeeper 正好要用来进行分布式环境的协调于是Zookeeper 的名字也就由此诞生了。
三种角色
① 领导者leader负责进行投票的发起和决议更新系统状态。
② 学习者learner包括跟随者follower和观察者observer。
follower 用于接受客户端请求并向客户端返回结果在选举过程中参与投票Observer 可以接受客户端连接将写请求转发给 leader但 observer 不参加投票过程只同步 leader 的状态observer 的目的是为了扩展系统提高读取速度
③ 客户端client请求发起方 一个 ZooKeeper 集群同一时刻只会有一个 LeaderZooKeeper 集群的所有机器通过选举过程来选定一台被称为 Leader 的机器Leader 服务器为客户端提供读和写服务。其他都是 Follower 或 Observer。
leader 负责客户端 writer 类型的请求,Follower 和 Observer 都能提供读服务不能提供写服务。两者唯一的区别在于Observer 不参与 Leader 选举过程也不参与写操作的『过半写成功』策略因此 Observer 可以在不影响写性能的情况下提升集群的读性能。
节点状态
每个集群中的节点都有一个状态 LOOKING, FOLLOWING, LEADING, OBSERVING。都属于这 4 种每个节点启动的时候都是 LOOKING 状态如果这个节点参与选举但最后不是 leader则状态是 FOLLOWING如果不参与选举则是 OBSERVINGleader的状态是 LEADING。
集群服务器数
ZooKeeper 官方建议集群服务器的数量为奇数这是因为一个 ZooKeeper 集群如果要对外提供可用的服务那么集群中必须要有过半的机器正常工作并且彼此之间能够正常通信。
基于这个特性如果想搭建一个能够允许 N 台机器 down 掉的集群那么就要部署一个由 2*N1 台服务器构成的 ZooKeeper 集群。因此一个由 3 台机器构成的 ZooKeeper 集群能够在挂掉 1 台机器后依然正常工作 而对于一个由 5 台服务器构成的 ZooKeeper 集群能够对 2 台机器挂掉的情况进行容灾。
注意如果是一个由 6 台服务器构成的 ZooKeeper 集群同样只能够挂掉 2 台机器因为如果挂掉 3 台剩下的机器就无法实现过半了。 zookeeper 有这样一个特性集群中只要有超过过半的机器是正常工作的那么整个集群对外就是可用的。
可伸缩性
ZooKeeper 为什么要引入 Observer 这个角色呢其实在 ZooKeeper 中引入Observer主要是为了使 ZooKeeper 具有更好的可伸缩性。那么何为可伸缩性
如果我们的工作负载可以通过给系统分配更多的资源来分担那么这个系统就是可伸缩的一个不可伸缩的系统却无法通过增加资源来提升性能甚至会在工作负载增加时性能会急剧下降。
Session
Session 是指客户端会话在 ZooKeeper 中客户端会话是指客户端和ZooKeeper 服务器之间的 TCP 长连接。
ZooKeeper 对外的服务端口默认是 2181客户端启动时首先会与服务器建立一个 TCP 连接从第一次连接建立开始客户端会话的生命周期也开始了通过这个连接客户端能够通过心跳检测和服务器保持有效的会话也能够向 ZooKeeper 服务器发送请求并接受响应同时还能通过该连接接收来自服务器的 Watch 事件通知。
在为客户端创建会话之前服务端首先会为每个客户端都分配一个 sessionID。sessionID 是Zookeeper 会话的一个重要标识许多与会话相关的运行机制都是基于这个 sessionID 的。因此无论是哪台服务器为客户端分配的 sessionID都务必保证全局唯一。
2、ZNode
zookeeper 节点分类
在 ZooKeeper 中节点分为两类:
第一类是指构成集群的机器我们称之为机器节点。第二类是指数据模型中的数据单元我们称之为数据节点 ZNode。
znode 节点
ZooKeeper 将所有数据存储在内存中维护一个类似文件系统的数据结构, 根节点为/每个子目录都被称作为 znode(目录节点)和文件系统一样我们能够自由的增加、删除 znode在一个 znode 下增加、删除子 znode唯一的不同在于 znode是可以存储数据的。
ZooKeeper 数据模型的结构整体上可以看作是一棵树每个节点称做一个 ZNode。 每个 ZNode 都可以通过其路径唯一标识在每个 ZNode 上可存储少量数据(默认是 1M, 可以通过配置修改, 通常不建议在 ZNode 上存储大量的数据)
znode 四种类型
① PERSISTENT-持久化目录节点客户端与 zookeeper 断开连接后该节点依旧存在
② PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点 客户端与 zookeeper 断开连接后该节点依旧存在只是 Zookeeper 给该节点名称进行顺序编号。
③ EPHEMERAL-临时目录节点 客户端与 zookeeper 断开连接后该节点被删除
④ EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点客户端与 zookeeper 断开连接后该节点被删除只是 Zookeeper 给该节点名称进行顺序编号。
znode 版本
Zookeeper 的每个 ZNode 上都会存储数据对应于每个 ZNodeZookeeper 都会为其维护一个叫作 Stat 的数据结构。Stat 中记录了这个 ZNode 的三个数据版本分别是
① version当前 ZNode 的版本
② cversion当前 ZNode 子节点的版本
③ aversion当前 ZNode 的 ACL 版本
Stat 里面的版本号表示的是对数据节点的内容、子节点列表或者 ACL 信息的修改次数。节点创建时 dataversion、aclversioncversion 都为 0每次修改响应内容其对应的版本号加 1。
Watcher
Watcher事件监听器,ZooKeeper 允许用户在指定节点上注册一些 Watcher并且在一些特定事件触发的时候ZooKeeper 服务端会将事件通知到感兴趣的客户端上去该机制是 ZooKeeper 实现分布式协调服务的重要特性。
注意ZooKeeper 中的 Watcher 是一次性的即触发一次就会被取消如果想继续 Watch 的话需要客户端重新设置 Watcher。
ACL
ZooKeeper 采用 ACLAccess Control Lists策略来进行权限控制。ZooKeeper 定义了如下 5 种权限:
CREATE创建子节点的权限。READ获取节点数据和子节点列表的权限。WRITE更新节点数据的权限。DELETE删除子节点的权限。ADMIN设置节点 ACL 的权限。
注意CREATE 和 DELETE 都是针对子节点的权限控制。
事务操作
ZooKeeper 中能改变 ZooKeeper 服务器状态的操作称为事务操作。一般包括数据节点创建与删除、数据内容更新和客户端会话创建与失效等操作。对应每一个事务请求ZooKeeper 都会为其分配一个全局唯一的事务 ID用 ZXID 表示每一个 ZXID 对应一次更新操作从这些 ZXID 中可以间接地识别出
ZooKeeper 处理这些事务操作请求的全局顺序。由于 zxid 的递增性质, 如果 zxid1 小于 zxid2, 那么zxid1 肯定先于 zxid2 发生。
实际上ZooKeeper 的每个节点维护着三个 zxid 值为别为cZxid、mZxid、pZxid。
cZxid 是该节点创建时所对应的事物 ID。mZxid是该节点最近一次被修改时所对应的事物 ID与其子节点无关。pZxid是该节点的子节点最近一次被修改时的事物 ID。
3、ZooKeeper 工作原理
Zookeeper 的核心是原子广播这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 Zab 协议。Zab 协议有两种模式它们分别是恢复模式和广播模式。
恢复模式
① 当服务启动或者 leader 崩溃或者 leader 失去大多数的 follower这时候zookeeper 进入恢复模式恢复模式需要重新选举出一个新的 leader让所有的 server 都恢复到一个正确的状态。
② 每个 Server 启动以后都询问其它的 Server 它要投票给谁。
③ 对于其他 server 的询问server 每次根据自己的状态都回复自己推荐的 leader的 id 和上一次处理事务的 zxid系统启动时每个 server 都会推荐自己
④ 收到所有 Server 回复以后就计算出 zxid 最大的哪个 Server并将这个 Server 相关信息设置成下一次要投票的 Server
⑤ 计算这过程中获得票数最多的 server 为获胜者如果获胜者的票数超过半数则该 server 被选为 leader。否则继续这个过程直到 leader 被选举出来。
⑥ leader 就会开始等待 server 连接
⑦ Follower 连接 leader将最大的 zxid 发送给 leader
⑧ Leader 根据 follower 的 zxid 确定同步点
⑨ 完成同步后通知 follower 已经成为 uptodate 状态
⑩ Follower 收到 uptodate 消息后又可以重新接受 client 的请求进行服务了
广播模式
一旦 leader 已经和过半数的 follower 进行了状态同步后他就可以开始广播消息了即进入广播状态。这时候当一个 server 加入 zookeeper 服务中它会在恢复模式下启动发现 leader并和 leader 进行状态同步。待到同步结束它也参与消息广播。Zookeeper 服务一直维持在 Broadcast 状态直到 leader 崩溃了或者 leader失去了大部分的 followers 支持。广播模式需要保证 proposal 被按顺序处理因此 zookeeper 采用了递增的事务 id号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了 zxid。
4、ZooKeeper 设计目标
ZooKeeper 是一种高性能、可扩展的服务。ZooKeeper 的读写速度非常快并且读的速度要比写快。它具有如下特点
① 顺序一致性从同一客户端发起的事务请求最终将会严格地按照顺序被应用到 ZooKeeper 中去。
② 原子性所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的也就是说要么整个集群中所有的机器都成功应用了某一个事务要么都没有应用。
③ 单一系统映像最终一致性无论客户端连到哪一个 ZooKeeper 服务器上其看到的服务端数据模型都是一致的。
④ 可靠性可靠性方面使其不会成为单点故障。
⑤ 实时性Zookeeper 保证客户端将在一个时间间隔范围内获得服务器的更新信息或者服务器失效的信息。但由于网络延时等原因Zookeeper 不能保证两个客户端能同时得到刚更新的数据如果需要最新数据应该在读数据之前调用 sync() 接口。
5、ZooKeeper 应用场景
ZooKeeper 是一个高可用的分布式数据管理与协调框架。基于对 ZAB 算法的实现 该框架能够很好地保证分布式环境中数据的一致性。也是基于这样的特性使得ZooKeeper 成为了解决分布式一致性问题的利器。
配置管理
zookeeper 提供了节点watch的功能zookeeper 的 client对外提供服务的 server监控 zookeeper 上的节点znode当节点变动的时候client 会收到变动事件和变动后的内容基于 zookeeper 的这个特性我们可以给服务器集群中的所有机器 client都注册 watch 事件监控特定 znode节点中存储部署代码的配置信息 需要更新代码的时候修改 znode 中的值服务器集群中的每一台 server 都会收到代码更新事件然后触发调用更新目标代码。
现在有很多开源项目使用 Zookeeper 来维护配置比如在 HBase 中客户端就是连接一个 Zookeeper获得必要的 HBase 集群的配置信息然后才可以进一步操作。 还有在开源的消息队列 Kafka 中也使用 Zookeeper 来维护 broker 的信息。
命令服务
命名服务也是分布式系统中比较常见的一类场景。在分布式系统中通过使用命名服务客户端应用能够根据指定名字来获取资源或服务的地址提供者等信息。 注册一个持久节点/service/business/what他下面的每个子节点都是一个可用服务 保 存 了 服 务 的 地 址 端 口 等 信 息 服 务 调 用 者 通 过 zookeeper 获 取 /service/business/what 所有子节点信息来得到可用的服务。
下面的节点都是临时节点服务器启动的时候会过来注册一个临时节点服务器挂掉之后或主动关闭之后临时节点会自动移除这样就可以保证使用者获取的 what 服务都是可用的而且可以动态的扩容缩容。
分布式协调/通知
ZooKeeper 中特有 Watcher 注册与异步通知机制能够很好的实现分布式环境下不同机器甚至不同系统之间的通知与协调从而实现对数据变更的实时处理。使用方法通常是不同的客户端都对 ZooKeeper 上同一个 ZNode 进行注册监听ZNode 的变化包括 ZNode 本身内容及子节点的如果 ZNode 发生了变化那么所有订阅的客户端都能够接收到相应的 Watcher 通知并做出相应的处理。 ZooKeeper 的分布式协调/通知是一种通用的分布式系统机器间的通信方式。
心跳检测
机器间的心跳检测机制是指在分布式环境中不同机器或进程之间需要检测到彼此是否在正常运行例如 A 机器需要知道 B 机器是否正常运行。在传统的开 发中我们通常是通过主机直接是否可以相互 PING 通来判断更复杂一点的话 则会通过在机器之间建立长连接通过 TCP 连接固有的心跳检测机制来实现上层 机器的心跳检测这些都是非常常见的心跳检测方法。 基于 ZooKeeper 的临时节点的特性可以让不同的进程都在 ZooKeeper 的一个指定节点下创建临时子节点不同的进程直接可以根据这个临时子节点来判断对应 的进程是否存活。通过这种方式检测和被检测系统直接并不需要直接相关联而是通过 ZooKeeper 上的某个节点进行关联大大减少了系统耦合。
6、ZooKeeper 工作流程
Leader 工作流程
Leader 主要有三个功能
① 恢复数据
② 维持与 Learner 的心跳接收 Learner 请求并判断 Learner 的请求消息类型
③ Learner 的消息类型主要有 PING 消息、REQUEST 消息、ACK 消息、根据不同的消息类型进行不同的处理。
PING 消息是指 Learner 的心跳信息REQUEST 消息是 Follower 发送的提议信息包括写请求及同步请求ACK 消息是 Follower 的对提议的回复超过半数的 Follower通过则 commit 该提议REVALIDATE 消息是用来延长 SESSION 有效时间。
Follower 工作流程
Follower 主要有四个功能
① 向 Leader 发送请求PING 消息、REQUEST 消息、ACK 消息、REVALIDATE 消息② 接收 Leader 消息并进行处理③ 接收 Client 的请求如果为写请求发送给 Leader 进行投票④ 返回 Client 结果。
Follower 的消息循环处理如下几种来自 Leader 的消息
① PING 消息 心跳消息
② PROPOSAL 消息Leader 发起的提案要求 Follower 投票
③ COMMIT 消息服务器端最新一次提案的信息
④ UPTODATE 消息表明同步完成
⑤ REVALIDATE 消息根据 Leader 的 REVALIDATE 结果关闭待 revalidate 的 session还是允许其接受消息
⑥ SYNC 消息返回 SYNC 结果到客户端这个消息最初由客户端发起用来强制得到最新的更新。
