Zookeeper入门

最新推荐文章于 2024-07-22 17:41:30 发布

酥络

最新推荐文章于 2024-07-22 17:41:30 发布

阅读量106

点赞数

分类专栏： Java Zookeeper 文章标签： java-zookeeper zookeeper 分布式后端 java

本文链接：https://blog.csdn.net/qq_39587013/article/details/128242723

版权

Java 同时被 2 个专栏收录

4 篇文章 0 订阅

订阅专栏

Zookeeper

1 篇文章 0 订阅

订阅专栏

什么是Zookeeper？

由来

Zookeeper最早起源于雅虎研究院的一个研究小组。在当时，研究人员发现，在雅虎内部很多大型系统基本都需要依赖一个类似的系统来进行分布式协调，但是这些系统往往都存在分布式单点问题。所以，雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架，以便让开发人员将精力集中在处理业务逻辑上。
关于“ZooKeeper”这个项目的名字，其实也有一段趣闻。在立项初期，考虑到之前内部很多项目都是使用动物的名字来命名的（例如著名的Pig项目),雅虎的工程师希望给这个项目也取一个动物的名字。时任研究院的首席科学家RaghuRamakrishnan开玩笑地说：“在这样下去，我们这儿就变成动物园了！”此话一出，大家纷纷表示就叫动物园管理员吧一一一因为各个以动物命名的分布式组件放在一起，雅虎的整个分布式系统看上去就像一个大型的动物园了，而Zookeeper正好要用来进行分布式环境的协调一一于是，Zookeeper的名字也就由此诞生了。【摘自《从Paxos到Zookeeper 》第四章第一节的某段内容】

概览

Zookeeper官网：https://zookeeper.apache.org/

ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications. Each time they are implemented there is a lot of work that goes into fixing the bugs and race conditions that are inevitable. Because of the difficulty of implementing these kinds of services, applications initially usually skimp on them, which make them brittle in the presence of change and difficult to manage. Even when done correctly, different implementations of these services lead to management complexity when the applications are deployed.
ZooKeeper是一个集中的服务，用于维护配置信息、命名、分布式同步和提供组服务。所有这些类型的服务都以某种形式被分布式应用程序使用。每次执行它们时，我们都要做大量的工作来修复不可避免的bug和竞争条件。由于实现这类服务的难度很大，应用程序最初通常会忽略它们，这使得它们在出现变化时变得脆弱，并且难以管理。即使正确执行，这些服务的不同实现在部署应用程序时也会导致管理复杂性。

版本Documentation： Because Coordinating Distributed Systems is a Zoo
ZooKeeper is a high-performance coordination service for distributed applications. It exposes common services - such as naming, configuration management, synchronization, and group services - in a simple interface so you don’t have to write them from scratch. You can use it off-the-shelf to implement consensus, group management, leader election, and presence protocols. And you can build on it for your own, specific needs.
ZooKeeper是一种高性能的分布式应用协调服务。它在一个简单的接口中公开公共服务——例如命名、配置管理、同步和组服务——因此您不必从头开始编写它们。您可以使用它来实现共识、组管理、领导者选举和存在协议。你可以根据自己的特殊需求来构建它。

ZooKeeper致力于提供一个高性能、高可用，且具备严格的顺序访问控制能力的分布式协调服务，是雅虎公司创建，是Google的Chubby一个开源的实现，也是Hadoop和Hbase的重要组件。Zookeeper采用了一种被称为ZAB（zookeeper Atomic Broadcast）的一致性协议。

它是一个分布式协调框架，是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等

zookeeper是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。

什么是分布式？

分布式系统

通常情况下，单个物理节点很容易达到性能，计算或者容量的瓶颈，所以这个时候就需要多个物理节点来共同完成某项任务，一个分布式系统的本质是分布在不同网络或计算机上的程序组件，彼此通过信息传递来协同工作的系统，而Zookeeper正是一个分布式应用协调框架，在分布式系统架构中有广泛的应用场景

分布式特点

分布性
分布式系统中的多台计算机在空间上是随意分布的
对等性
分布式系统的计算机没有主从之分，副本是对主机的冗余备份，是解决数据丢失的一种手段
并发性
在同一时刻存在不同用户同时访问一些共享资源，比如数据库和分布式存储等
缺乏全局时钟
分布式主机可能存在时间不一致的情况，这就导致不同的调用之间很难判断谁先谁后。
故障总是会发生
在设计阶段考虑到的异常，一定会在系统实际运行中发生，除非需求指标允许，设计时不要放过任何异常。

随着分布式的出现，传统的单机事务已经无法胜任。如果期望一套严格满足ACID特性的分布式事务，很可能会在系统的可用性和严格一致性上出现冲突。而可用性和一致性都是用户的刚需。为了兼顾可用性和一致性，出现了CAP和BASE这样的经典理论。

CAP理论

一致性（C）
对于一个将数据分布到不同的分布式节点的系统来说，当你更新第一个节点的时候，要保证也能够更新第二个节点，不能是用户读第二个节点是出现脏读，这样的系统才是严格一致性的

可用性（A）
对于用户的每一个请求，都希望在有限的时间内返回结果，有限的时间指的是系统设计的响应时间，返回结果是一个正常的要么成功要么失败的结果，而不是一个用户看不懂的结果。

分区容错性（P）
在遇到网络分区的时候，仍然需要保证提供一致性的可用服务。比如不同机房的部署结构，机房之间通信异常
请注意一个分布式系统无法同时满足上述三个需求，只能满足其中两项！！

CAP取舍

放弃P
避免出现分区容错，只能将数据和服务都放在一个节点上，充分保证系统的可用性和一致性。但放弃P意味着放弃了系统的可扩展性

放弃A
当节点故障或者网络故障时，受到影响的服务需要等待一定的世界，因此在等待时间里，系统无法对外提供正常服务，因此是不可用的；

放弃C
放弃一致性，不是指系统不要一致性，不要一致性的系统是没有意义的，放弃C指的是不要求强一致性，需要最终一致性，这就需要有一个时间窗口，这个时间窗口指的是系统需要多久才能达到最终一致性。

在分布式中CAP理论中的P是一个最基本的要求，因为是分布式，分布式组件必然是部署到不同的节点的。所以我们只要在C和A中找平衡。

BASE理论

BASE是Basically Available（基本可用），Soft state（软状态）和Eventually consistent（最终一致性）的简写。BASE是对CAP中一致性和可用性的一个权衡，核心思想是即使无法做到强一致性，但系统要达到最终一致性。

基本可用
允许损失部分可用性，不等价于系统不可用。具体损失表现在：响应时间上的损失，功能上的损失（峰值并发时可能会引导到一个降级的页面）e.g：部分用户双十一高峰期淘宝页面卡顿或降级处理；
弱状态
即允许数据存在中间状态，允许数据在不同节点进行数据同步时存在延时。e.g：12306网站卖火车票，请求会进入排队队列；
最终一致性
系统间的所有数据副本，在经过一段时间同步后，最终能够达到一致性。不需要实时一致性e.g：理财产品首页充值总金额短时不一致；

分布式一致性协议

为了解决分布式一致性问题，涌现了一大批经典的一致性协议和算法，最有名的有二阶段提交协议、三阶段提交协议和Paxos算法。

当一个事务操作需要跨越多个分布式节点时，为了保持事务处理的ACID特性，就需要引入一个“协调者”的组件来统一调度所有分布式节点的执行，这些被调度的分布式节点则称为“参与者”，协调者负责调度参与者的行为，并最终决定这些参与者是否要把事务真正提交。

基于这种思想，衍生出了二阶段（2PC二阶段协议）和三阶段提交协议（3PC三阶段协议）。

2PC二阶段协议

2PC是Two-Phase Commit的缩写，目前绝大部分的关系型数据库都是采用二阶段提交协议来完成分布式事务处理的。
顾名思义，二阶段提交协议是将事务的提交过程分成两个阶段来进行处理

阶段一：提交事务请求
阶段一也被称为“投票阶段”。即个参与者投票表明是否需要继续执行接下去的事务提交操作。

阶段二：执行事务提交
在阶段二中，协调者会根据各参与者反馈的情况来决定最终是否进行事务提交

二阶段提交示意图
优缺点
优点：原理简单，实现方便

缺点：同步阻塞、单点问题、数据不一致
同步阻塞：各参与者都需要等待其他参与者的响应，期间什么都做不了
单点问题：协调者有明显的单点问题
数据不一致：协调者发送部分节点commit指令后挂了，数据出现不一致

3PC三阶段协议

2PC在运行中存在同步阻塞、协调者单点问题、数据不一致的问题，因此在其基础上进行了改进，提出了三阶段协议。
3PC，是Three-Phase Commit的缩写，是2PC的改进版

阶段一：CanCommit

阶段二：PreCommit

阶段三：doCommit

与两阶段提交不同的是，三阶段提交有两个改动点：
1、引入超时机制。同时在协调者和参与者中都引入超时机制。
2、在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。
也就是说，除了引入超时机制之外，3PC把2PC的准备阶段再次一分为二，这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。

相对于2PC，3PC主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

了解了2PC和3PC后，两者都无法彻底解决分布式一致性问题。

Paxos算法

Paxos是一种基于消息传递且具有高度容错性的一致性算法，是目前公认的解决分布式一致性问题的最有效的算法之一。

算法陈述：

阶段一：
1、Proposer选择一个提案编号Mn，然后向Acceptor的某个超过半数的子集成员发送编号为Mn的Prepare请求。
2、如果一个Acceptor收到一个编号为Mn的Prepare请求，且编号Mn大于该Acceptor已经响应的所有Prepare请求的编号，那么它就会将它已经批准过的最大编号的提案作为响应反馈给Proposer，同时该Acceptor会承诺不会再批准任何编号小于Mn的提案。

举个例子，假定一个Acceptor已经响应过的所有Prepare请求对应的提案编号分别是1、2…、5和7，那么该Acceptor在接收到一个编号为8的Prepare请求后，就会将编号为7的提案作为响应反馈给Proposer。

阶段二：
1、如果Proposer收到来自半数以上的Acceptor对于其发出的编号为Mn的Prepare请求的响应，那么它就会发送一个针对[Mn，Vn]提案的Accept请求给Acceptor。注意，Vn的值就是收到的响应中编号最大的提案的值，如果响应中不包含任何提案，那么它就是任意值。
2、如果Acceptor收到这个针对[Mn，Vn]提案的Accept请求，只要该Acceptor尚未对编号大于Mn的Prepare请求做出响应，它就可以通过这个题案。

为什么使用Zookeeper | Zookeeper能做什么？

典型的应用场景有分布式配置中心、分布式注册中心、分布式锁、分布式队列、集群选举、分布式屏障、发布/订阅等场景。

应用场景

分布式配置中心
分布式注册中心
分布式锁
分布式队列
集群选举
分布式屏障
发布/订阅

Zookeeper特性及相关命令

数据模型

Zookeeper数据的组织形式为一个类似文件系统的数据结构，而这些数据都是存储在内存中的，所以我们可以认为，Zookeeper是一个基于内存的小型数据库

public class DataTree { 
	private final ConcurrentHashMap<String, DataNode> nodes = new ConcurrentHashMap<String, DataNode>();
	private final WatchManager dataWatches = new WatchManager();
	private final WatchManager childWatches = new WatchManager();

DataNode 是Zookeeper存储节点数据的最小单位

 public class DataNode implements Record { 
 	byte data[]; 
 	Long acl; 
 	public StatPersisted stat;
 	private Set<String> children = null;

节点

数据节点（Znode）
zookeeper将所有的数据存储在内存中，数据模型是一棵树（Znode Tree），由斜杆进行分割的路径，就是一个Znode，每个Znode上都会保存自己的数据内容，同时还会保存一些列的属性信息。
在zookeeper中，Znode分为持久节点和临时节点，持久节点是指一旦创建，除非主动删除，否则这个Znode会一直在Zookeeper中，临时节点它的生命周期是跟会话绑定，一旦客户端会话失效，临时节点将会删除。另外，zookeeper可以为每个节点添加SEQUENTIAL属性，一旦有这个属性，那么节点就是一个有序节点。

ACL机制

Zookeeper 的ACL 权限控制,可以控制节点的读写操作,保证数据的安全性，Zookeeper ACL 权限设置分为 3 部分组成，分别是：权限模式（Scheme）、授权对象（ID）、权限信息（Permission）。最终组成一条例如“scheme: id:permission”格式的 ACL 请求信息。这 3 部分表示：
Scheme（权限模式）：
用来设置 ZooKeeper 服务器进行权限验证的方式。
ZooKeeper 的权限验证方式大体分为以下几种类型：

范围验证。所谓的范围验证就是说 ZooKeeper 可以针对一个 IP 或者一段 IP 地址授予某种权限；比如我们可以让一个 IP 地址为“ip：192.168.0.110”的机器对服务器上的某个数据节点具有写入的权限。或者也可以通过“ip:192.168.0.1/24”给一段 IP 地址的机器赋权。
口令验证，也可以理解为用户名密码的方式。在 ZooKeeper 中这种验证方式是 Digest 认证，而 Digest 这种认证方式首先在客户端传送“username:password”这种形式的权限表示符后，ZooKeeper 服务端会对密码部分使用 SHA-1 和 BASE64 算法进行加密，以保证安全性。
Super权限模式, Super可以认为是一种特殊的 Digest 认证。具有 Super 权限的客户端可以对 ZooKeeper 上的任意数据节点进行任意操作。

授权对象（ID）
授权对象就是说我们要把权限赋予谁，而对应于 4 种不同的权限模式来说，如果我们选择采用 IP 方式，使用的授权对象可以是一个 IP 地址或 IP 地址段；而如果使用 Digest 或 Super 方式，则对应于一个用户名。如果是 World 模式，是授权系统中所有的用户。
权限信息（Permission）
权限就是指我们可以在数据节点上执行的操作种类，如下所示：在 ZooKeeper 中已经定义好的权限有 5 种：

数据节点（c: create）创建权限，授予权限的对象可以在数据节点下创建子节点；
数据节点（w: wirte）更新权限，授予权限的对象可以更新该数据节点；
数据节点（r: read）读取权限，授予权限的对象可以读取该节点的内容以及子节点的列表信息；
数据节点（d: delete）删除权限，授予权限的对象可以删除该数据节点的子节点；
数据节点（a: admin）管理者权限，授予权限的对象可以对该数据节点体进行 ACL 权限设置。

版本

zookeeper会对每一个Znode维护一个Stat的数据结构，Stat中记录了Znode的三个数据版本，分别是version（当前Znode的版本）、cversion（当前Znode子节点的版本）和aversion（当前Znode的ACL版本）

参考资料：
zookeeper前世今生

酥络

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
1
评论
Zookeeper入门

Zookeeper最早起源于雅虎研究院的一个研究小组。在当时，研究人员发现，在雅虎内部很多大型系统基本都需要依赖一个类似的系统来进行分布式协调，但是这些系统往往都存在分布式单点问题。所以，雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架，以便让开发人员将精力集中在处理业务逻辑上。关于“ZooKeeper”这个项目的名字，其实也有一段趣闻。在立项初期，考虑到之前内部很多项目都是使用动物的名字来命名的（例如著名的Pig项目),雅虎的工程师希望给这个项目也取一个动物的名字。
复制链接

扫一扫