赞
踩
zooKeeper 是一个分布式的,开放源码的分布式应用程序协调服务,是 Google 的 Chubby 一个开源的实现,是 Hadoop 和 Hbase 的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。ZooKeeper 的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、 功能稳定的系统提供给用户。ZooKeeper 包含一个简单的原语集, 提供 Java 和 C 的接口 ,ZooKeeper 代码版本中,提供了分布式独享锁、选举、队列的接口,代码在 zookeeper-3.4.3\src\recipes。其中分布锁和队列有 Java 和 C 两个版本,选举只有 Java 版本
Zookeeper 是一个分布式协调服务,可用于服务发现,分布式锁,分布式领导选举,配置管理等。
Zookeeper 提供了一个类似于 Linux 文件系统的树形结构(可认为是轻量级的内存文件系统,但只适合存少量信息,完全不适合存储大量文件或者大文件),同时提供了对于每个节点的监控与通知机制
ZooKeeper 提供了什么:文件系统和通知机制
Zookeeper的出现,主要是为了满足分布式环境中,以上三种常见的场景需求,作为一个分布式的中间件而存在。它相当于是一个分布式开源的协调组件。简单理解,就相当于是一个裁判员的角色,专门负责协调和解决分布式系统中的各类问题。
总的来说,Zookeeper 就是经典的分布式数据一致性解决方案,致力于为分布式应用提供高性能、高可用,并且具有严格顺序访问控制能力的分布式协调服务。它底层通过基于 Paxos 算法演化而来的 ZAB 协议实现。
1.服务注册与订阅(共用节点)
2.分布式通知(监听ZNode)
3.服务命令(ZNode特性)
4.数据订阅、发布(Watcher)
5.分布式锁(临时节点)
ZooKeeper 是以 Fast Paxos 算法为基础的,Paxos 算法存在活锁的问题,即当有多个 proposer 交错提交时,有可能互相排斥导致没有一个 proposer 能提交成功,而 Fast Paxos 作了一些优化,通过选举产生一个 leader (领导者),只有 leader 才能提交 proposer,具体 算法可见 Fast Paxos。因此,要想弄懂 ZooKeeper 首先得对 Fast Paxos 有所了解。
ZooKeeper 的基本运转流程:
1、选举 Leader。
2、同步数据。
3、选举 Leader 过程中算法有很多,但要达到的选举标准是一致的。
4、Leader 要具有最高的执行 ID,类似 root 权限。
5、集群中大多数的机器得到响应并 follow选出的 Leader。
数据结构Znode:zookeeper数据采⽤树形层次结构,和标准⽂件系统⾮常相似,树中每个节点被称为Znode;
通知机制Watcher:zookeeper可以为所有的读操作(exists()、getChilden()及getData())设置watch,watch事件是⼀次性出发器,当watch的对象状态发⽣改变时,将会触发次对象上watch所对应的事件。watch事件将被异步的发送给客户端,并且zookeeper为watch机制提供了有序的⼀致性保证。
基本流程:分布式锁应用场景
1、传统的⼀主n从分布式系统,容易发⽣单点故障,传统解决方式是增加⼀个备⽤节点,定期给主节点发送Ping包,主节点回复ack,但是如果⽹络原因ack丢失,那么会出现两个主节点,造成数据混乱。
2、zookeeper的引⼊可以管理两个主节点,其中挂了一个,会将另外⼀个作为新的主节点,挂的节点回来时担任备⽤节点;
ZooKeeper、Nacos、Eureka 和 Consul 都是常见的服务发现和配置中心工具,它们在分布式系统中扮演着重要的角色,但在某些方面有一些区别。
ZooKeeper:
● 角色:ZooKeeper 最初设计作为一个分布式协调服务,用于提供分布式锁、命名服务、配置管理等功能。
● 一致性:ZooKeeper 采用 ZAB 协议(ZooKeeper Atomic Broadcast)保证数据一致性。
● 特点:ZooKeeper 是 Apache 软件基金会的顶级项目,稳定性高,被广泛应用于分布式系统。
● 使用场景:主要用于分布式协调和一致性需求,如分布式锁、队列等。
Nacos:
● 角色:Nacos 是阿里巴巴开源的注册中心和配置中心,支持服务发现、服务健康检查、动态配置等功能。
● 特点:Nacos 支持多种注册中心和配置中心模式,包括基于 DNS 和基于 RPC 的服务发现。
● 优势:Nacos 功能较为全面,支持更多新特性,如动态配置管理、服务路由等。
Eureka:
● 角色:Eureka 是 Netflix 开源的服务发现组件,主要用于服务注册与发现。
● 特点:Eureka 采用了 CAP 原则中的 AP 模型,即可用性优先,对一致性要求相对较低。
● 优势:Eureka 相对简单易用,适合快速搭建微服务架构。
Consul:
● 角色:Consul 是 HashiCorp 公司开源的服务网格解决方案,集成了服务发现、健康检查、KV 存储等功能。
● 特点:Consul 提供了一体化的服务注册和发现解决方案,支持多数据中心部署,具有较好的可扩展性和灵活性。
● 优势:Consul 对多数据中心支持较好,适合复杂环境下的服务治理需求。
总的来说,ZooKeeper 更注重分布式协调和一致性,Nacos 提供了更全面的服务注册与配置管理功能,Eureka 简单易用适合快速搭建微服务,Consul 则更适合复杂环境下的服务发现和治理需求。选择合适的工具取决于具体的业务场景和需求。
ZooKeeper 是一个开源的分布式应用程序协调服务,它提供了一个具有高度可靠性的分布式协调和同步的解决方案。ZooKeeper 使用了一些关键的数据结构来管理和维护其状态,这些数据结构主要包括:
这些数据结构和机制共同构成了 ZooKeeper 的核心功能,使其能够有效地用于分布式系统中的协调和同步。
解决ZooKeeper(ZK)集群脑裂问题的方法可以从多个方面入手。ZooKeeper是一个分布式协调服务,用于协调和管理分布式系统中的各种数据和状态信息,因此避免集群脑裂对于整个分布式系统的稳定性非常重要。
以下是一些解决ZooKeeper集群脑裂问题的建议:
ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持崩溃恢复的原子广播协议。
ZAB 协议包括两种基本的模式:崩溃恢复和消息广播。
当整个 zookeeper 集群刚刚启动或者 Leader 服务器宕机、重启或者网络故障 导致不存在过 半的服务器与 Leader 服务器保持正常通信时,所有进程(服务 器)进入崩溃恢复模式,首 先选举产生新的 Leader 服务器,然后集群中 Follower 服务器开始与新的 Leader 服务器进 行数据同步,当集群中超过半数 机器与该 Leader 服务器完成数据同步之后,退出恢复模式 进入消息广播模 式,Leader 服务器开始接收客户端的事务请求生成事物提案来进行事务请求处理。
可以选 Zookeeper,memcached,redis 等。
命名服务,服务提供者向 Zookeeper 指定节点写入 url,完成服务发布。
负载均衡,注册中心承载能力有限,而 Zookeeper 集群配合 web 应用很容易达到负载均衡。
zk 支持监听事件,特别适合发布/订阅场景,dubbo生产者和消费者就类似这场景。
数据模型简单,数据存在内存,可谓高性能
Dubbo 选择 Zookeeper 作为注册中心的原因有以下几点
你运行一个zookeeper也是可以的,但是在生产环境中,你最好部署3,5,7个节点。部署的越多,可靠性就越高,当然只能部署奇数个,偶数个是不可以的(zookeeper有这样一个特性:集群中只要有过半的机器是正常工作的,那么整个集群对外就是可用的。也就是说如果有2个zookeeper,那么只要有1个死了zookeeper就不能用了,因为1没有过半,所以2个zookeeper的死亡容忍度为0;同理,要是有3个zookeeper,一个死了,还剩下2个正常的,过半了,所以3个zookeeper的容忍度为1;同理你多列举几个:2->0;3->1;4->1;5->2;6->2会发现一个规律,2n和2n-1的容忍度是一样的,都是n-1,所以为了更加高效,何必增加那一个不必要的zookeeper呢)。你需要给每个zookeeper 1g左右的内存,如果可能的话,最好有独立的磁盘。 (独立磁盘可以确保zookeeper是高性能开发的。).如果你的集群负载很重,不要把zookeeper和regionserver运行在同一台机器上面。就像datanodes 和 tasktrackers一样
Zookeeper 是基于临时顺序节点以及 Watcher 监听器机制实现分布式锁的。
1.ZooKeeper 的每一个节点都是一个天然的顺序发号器。
2.ZooKeeper 节点的递增有序性可以确保锁的公平。
3.ZooKeeper 的节点监听机制,可以保障占有锁的传递有序而且高效
Zookeeper实现分布式锁原理:
Zookeeper节点路径不能重复 保证唯一性。 临时节点+事件通知
1.获取锁方法:
多个jvm同时在zk上创建一个临时节点/lockPath,
最终只能够有一个jvm创建临时节点成功,如果能够创建
临时节点成功jvm 表示获取锁成功能够正常执行业务逻辑,
如果没有创建临时节点成功的jvm,则表示获取锁失败。
获取锁失败之后,可以采用不断重试策略,重试多次
获取锁失败之后,当前的jvm就进入到阻塞状态。
2.释放锁方法:
直接调用.close();释放锁
因为采用临时节点,当我们调用close()方法的时候
该临时节点会自动被删除。
其他没有获取到锁的jvm,就会从新进入到获取锁的状态。
3.被唤醒的方法:
被阻塞的jvm(没有获取锁成功的jvm),采用事件监听的方式
监听到节点已经被删除的情况下,则开始从新进入到获取锁的状态。
Zookeeper 实现分布式锁的方法比较多,我们可以使用有序节点来实现,
1、来看这个图,每个线程或进程在 Zookeeper 上的/lock 目录下创建一个临时有序的节点表示去抢占锁,所有创建的节点会按照先后顺序生成一个带有序编号的节点。
2、线程创建节点后,获取/lock 节点下的所有子节点,判断当前线程创建的节点是否是所有的节点的序号最小的。
3、如果当前线程创建的节点是所有节点序号最小的节点,则认为获取锁成功。
4、如果当前线程创建的节点不是所有节点序号最小的节点,则对节点序号的前个节点添加一个事件监听,当前一个被监听的节点释放锁之后,触发回调通知,从而再次去尝试抢占锁。
ZooKeeper 是一种分布式协调服务,它可以帮助分布式系统中的各个节点进行协调和通信。ZooKeeper 的协调机制是通过一种称为 “ZNode” 的数据结构来实现的。
在 ZooKeeper 中,每个节点都被称为一个 ZNode,它可以有子节点和关联的数据。ZNode 可以被视为一种目录结构,其中每个节点都有一个路径。通过这个路径,可以找到节点的数据。
当使用 ZooKeeper 实现分布式锁时,可以使用一种称为 “顺序节点” 的机制。顺序节点是一种特殊的 ZNode,它会在创建时自动分配一个唯一的顺序编号。这个编号可以用来解决分布式锁的问题。
假设我们有一个需要被协调的任务,可以让多个进程都去创建 ZooKeeper 中的同一家目录下的一个子节点。由于是顺序节点,每个进程创建的子节点都会被分配一个唯一的编号。当一个进程创建了编号最小的子节点时,就认为它获得了锁,可以执行任务。其他进程在创建子节点时会被阻塞,等待前一个进程释放锁。
这个过程中,只要有一台机器能够成功创建子节点并获得锁,就可以完成任务。其他机器会继续等待,直到锁被释放。这样可以保证只有一个进程能够执行任务,实现分布式锁的效果。
总之,ZooKeeper 提供了分布式协调的机制,可以通过顺序节点实现分布式锁的功能,使得分布式系统中的任务可以被协调执行。
Zookeeper是一个分布式协调组件,为分布式架构下的多个应用组件提供了顺序访问控制能力。
它的数据存储采用了类似于文件系统的树形结构,以节点的方式来管理存储在Zookeeper上的数据
Zookeeper提供了一个Watch机制,可以让客户端感知到Zookeeper Server上存储的数据变化,这样一种机制可以让Zookeeper实现很多的场景,比如配置中心、注册中心等。
Watch机制采用了Push的方式来实现,也就是说客户端和Zookeeper Server会建立一个长连接,一旦监听的指定节点发生了变化,就会通过这个长连接把变化的事件推送给客户端。
Watch的具体流程分为几个部分:
首先,是客户端通过指定命令比如exists、get,对特定路径增加watch
然后服务端收到请求以后,用HashMap保存这个客户端会话以及对应关注的节点路径,同时客户端
也会使用HashMap,存储指定节点和事件回调函数的对应关系。
当服务端指定被watch的节点发生变化后,就会找到这个节点对应的会话,把变化的事件和节点信息
发给这个客户端。客户端收到请求以后,从ZkWatcherManager里面对应的回调方法进行调用,完成事件变更的通知。
ZooKeeper 中的 Watch 机制是一种事件通知机制,在节点数据发生变化时,可以通知客户端进行相应的处理。以下是 ZooKeeper 中 Watch 机制的原理:
Zookeeper集群节点由三种角色组成,分别是Leader,负责所有事务请求的处理,以及过半提交的投票发起和决策。Follower,负责接收客户端的非事务请求,而事务请求会转发给Leader节点来处理, 另外,
Follower节点还会参与Leader选举的投票。Observer,负责接收客户端的非事务请求,事务请求会转发给Leader节点来处理,另外Observer节点不参与任何投票,只是为了扩展Zookeeper集群来分担读操作的压力
其次,Zookeeper集群是一种典型的中心化架构,也就是会有一个Leader作为决策节点,专门负责事务请求的处理和数据的同步。这种架构的好处是可以减少集群架构里面数据同步的复杂度,集群管理会更加简单和稳定。但是,会带来Leader选举的一个问题,也就是说,如果Leader节点宕机了,为了保证集群继续提供可靠的服务,Zookeeper需要从剩下的Follower节点里面去选举一个新的节点作为Leader,也就是所谓的Leader选举
具体的实现是,每一个节点都会向集群里面的其他节点发送一个票据Vote,这个票据包括三个属性。
epoch, 逻辑时钟,用来表示当前票据是否过期。
zxid,事务id,表示当前节点最新存储的数据的事务编号。
myid,服务器id,在myid文件里面填写的数字。
每个节点都会选自己当Leader,所以第一次投票的时候携带的是当前节点的信息。
接下来每个节点用收到的票据和自己节点的票据做比较,根据epoch、zxid、myid的顺序逐一比较,以值最大的一方获胜。比较结束以后这个节点下次再投票的时候,发送的投票请求就是获胜的Vote信息。然后通过多轮投票以后,每个节点都会去统计当前达成一致的票据,以少数服从多数的方式,最终获得票据最多的节点成为Leader。
以上就是我对这个问题的理解。
最后我再补充一下,选择epoch/zxid/myid作为投票评判依据的原因,我是这么理解的。
epoch ,因为网络通信延迟的可能性,有可能在新一轮的投票里面收到上一轮投票的票据,这种数据应该丢弃,否则会影响投票的结果和效率。
zxid,zxid越大,说明这个节点的数据越接近leader,所以用zxid做判断条件是为了避免数据丢失的问题。myid, 服务器id,这个是避免投票时间过长,直接用myid最大值作为快速终结投票的属性。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。