卓成建设集团有限公司网站,整站优化全网营销,网络工程师报名入口官网,推广app文案文章目录 Zookeeper 概念ZooKeeper的应用场景使用场景zk的原理ZooKeeper、Nacos、Eureka 和 Consul区别Zookeeper的数据结构zk集群脑裂如何解决ZAB 协议假如注册中心挂了#xff0c;消费者还能调⽤服务吗#xff0c;用什么调用的dubbo注册中心为什么选择 Zookeeper关于zookee… 文章目录 Zookeeper 概念ZooKeeper的应用场景使用场景zk的原理ZooKeeper、Nacos、Eureka 和 Consul区别Zookeeper的数据结构zk集群脑裂如何解决ZAB 协议假如注册中心挂了消费者还能调⽤服务吗用什么调用的dubbo注册中心为什么选择 Zookeeper关于zookeeper部署的个数Zk分布式锁原理和实现zk中的Watch机制的原理Zk实现Leader选举 Zookeeper 概念
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的出现主要是为了满足分布式环境中以上三种常见的场景需求作为一个分布式的中间件而存在。它相当于是一个分布式开源的协调组件。简单理解就相当于是一个裁判员的角色专门负责协调和解决分布式系统中的各类问题。 总的来说Zookeeper 就是经典的分布式数据一致性解决方案致力于为分布式应用提供高性能、高可用并且具有严格顺序访问控制能力的分布式协调服务。它底层通过基于 Paxos 算法演化而来的 ZAB 协议实现。 1.服务注册与订阅共用节点 2.分布式通知监听ZNode 3.服务命令ZNode特性 4.数据订阅、发布Watcher 5.分布式锁临时节点
集群管理 Zookeeper 提供了 CP 的模型来保证集群中的每个节点的数据一致性当然Zk 本身的集群并不是 CP 模型而是顺序一致性模型如果要保证 CP 特性需要调用 sync 同步方法。 在多个节点组成的集群中为了保证集群的 HA 特性每个节点都会冗余一份数据副本。这种情况下需要保证客户端访问集群中的任意一个节点都是最新的数据。分布式锁 Zookeeper 提供了多种不同的节点类型如持久化节点、临时节点、有序节点、容器节点等其中对于分布式锁这个场景来说Zookeeper 可以利用有序节点的特性来实现。除此之外还可以利用同一级节点的唯一性特性来实现分布式锁。 对某一个数据联系发出两个修改操作两台机器同时收到请求但是只能一台 机器先执行另外一个机器再执行那么此时就可以使用 zk 分布式锁一个机器接收到了 请求之后先获取 zk 上的一把分布式锁就是可以去创建一个 znode接着执行操作然 后另外一个机器也尝试去创建那个 znode结果发现自己创建不了因为被别人创建了 那只能等着等等一个机器执行完了自己再执行。 如何保证跨进程的共享资源的并发安全性对于分布式系统来说也是一个比较大的挑战而为了达到这样一个目的必须要使用跨进程的锁也就是分布式锁来实现。Master 选举 Zookeeper 可以利用持久化节点来存储和管理其他集群节点的信息从而进行Master 选举机制。或者还可以利用集群中的有序节点特性来实现 Master 选举。目前主流的 Kafka、Hbase、Hadoop 都是通过 Zookeeper 来实现集群节点的主从选举。 在多个节点组成的集群中为了降低集群数据同步的复杂度一般会存在 Master和 Slave 两种角色的节点Master 负责事务和非事务请求处理Slave 负责非事务请求处理。但是在分布式系统中如何确定某个节点是 Master 还是 Slave也成了一个难度不小的挑战。 4.分布式协调这个其实就是 zk 很经典的一个用法简单来说就好比你系统 A 发送个 请求到 mq然后 B 消费了之后处理。那 A 系统如何指导 B 系统的处理结果用 zk 就可 以实现分布式系统之间的协调工作。A 系统发送请求之后可以在 zk 上对某个节点的值注 册个监听器一旦 B 系统处理完了就修改 zk 那个节点的值A 立马就可以收到通知完美解决。 5.配置信息管理zk 可以用作很多系统的配置信息的管理比如 kafkastorm 等等很多分 布式系统都会选用 zk 来做一些元数据配置信息的管理包括 dubbo 注册中心不也支持 zk 么。 6.HA 高可用性这个应该是很常见的比如 hdfsyarn 等很多大数据系统都选择基于 zk 来发 HA 高可用机制就是一个重要进程一般会主备两个主进程挂了立马通过 zk 感知到切换到备份进程
zk的原理
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。 数据结构Znodezookeeper数据采⽤树形层次结构和标准⽂件系统⾮常相似树中每个节点被称为Znode 通知机制Watcherzookeeper可以为所有的读操作exists()、getChilden()及getData()设置watchwatch事件是⼀次性出发器当watch的对象状态发⽣改变时将会触发次对象上watch所对应的事件。watch事件将被异步的发送给客户端并且zookeeper为watch机制提供了有序的⼀致性保证。 基本流程分布式锁应用场景 1、传统的⼀主n从分布式系统容易发⽣单点故障传统解决方式是增加⼀个备⽤节点定期给主节点发送Ping包主节点回复ack但是如果⽹络原因ack丢失那么会出现两个主节点造成数据混乱。 2、zookeeper的引⼊可以管理两个主节点其中挂了一个会将另外⼀个作为新的主节点挂的节点回来时担任备⽤节点
ZooKeeper、Nacos、Eureka 和 Consul区别
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 使用了一些关键的数据结构来管理和维护其状态这些数据结构主要包括
ZNodeZooKeeper节点 ○ ZooKeeper 的基本数据单元。 ○ 它类似于文件系统中的节点但是它们是内存中的数据结构。 ○ 每个 ZNode 都有一个路径名路径名用斜杠/分隔类似于文件系统中的绝对路径。节点树Node Tree ○ ZooKeeper 维护一个由 ZNode 组成的层次化节点树。 ○ 树的根节点被称为 “/”并且所有的其他节点都是相对于根节点的路径来定义的。Watchers监视器 ○ Watchers 是在节点发生变化时通知客户端的机制。 ○ 客户端可以在 ZNode 上设置 Watcher以便在该节点的数据发生更改、被删除或子节点更改时收到通知。数据模型 ○ 每个 ZNode 都可以包含数据和子节点。 ○ 数据是存储在每个 ZNode 中的字节流。 ○ 每个 ZNode 可以拥有多个子节点每个子节点都有唯一的路径名。ACL访问控制列表 ○ ZooKeeper 使用 ACL 控制对 ZNode 的访问权限。 ○ 每个 ZNode 都有一个 ACL它规定了谁可以对其执行读、写、创建和删除等操作。版本号 ○ 每个 ZNode 都有一个版本号。 ○ 版本号用于标识 ZNode 的状态变化包括数据和子节点的变化。临时节点和顺序节点 ○ ZooKeeper 支持临时节点和顺序节点。 ○ 临时节点在客户端会话结束时被删除。 ○ 顺序节点在创建时会被自动分配一个唯一的递增顺序号。
这些数据结构和机制共同构成了 ZooKeeper 的核心功能使其能够有效地用于分布式系统中的协调和同步。
zk集群脑裂如何解决
解决ZooKeeperZK集群脑裂问题的方法可以从多个方面入手。ZooKeeper是一个分布式协调服务用于协调和管理分布式系统中的各种数据和状态信息因此避免集群脑裂对于整个分布式系统的稳定性非常重要。 以下是一些解决ZooKeeper集群脑裂问题的建议
奇数节点建议使用奇数个节点组成ZooKeeper集群这样在遇到网络分区时能够更容易地保持大多数节点的一致性。Quorum设置通过设置适当的Quorum配置确保在发生网络分区时仍然能够保持大多数节点的一致性避免脑裂问题的发生。自动选主配置ZooKeeper集群在发生领导者节点故障时能够自动选举新的领导者避免因为领导者节点故障引起的脑裂问题。网络配置合理配置网络参数尽量减少网络延迟和丢包等问题提高集群的通信可靠性。监控与报警建立完善的监控系统对ZooKeeper集群的状态进行实时监控并设置相应的报警机制及时发现并处理潜在的脑裂问题。节点健康检测定期对ZooKeeper集群中的各个节点进行健康状态检测及时发现故障节点并进行处理。自动恢复实现自动故障转移和自动恢复机制确保在发生节点故障或网络分区后集群能够自动进行恢复和重新配置避免脑裂问题的持续影响。 通过以上措施可以有效地减少ZooKeeper集群脑裂问题的发生提高整个分布式系统的稳定性和可靠性。同时还需要根据具体的环境和需求结合实际情况进行更详细的系统设计和优化。
ZAB 协议
ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持崩溃恢复的原子广播协议。 ZAB 协议包括两种基本的模式崩溃恢复和消息广播。 当整个 zookeeper 集群刚刚启动或者 Leader 服务器宕机、重启或者网络故障 导致不存在过 半的服务器与 Leader 服务器保持正常通信时所有进程服务 器进入崩溃恢复模式首 先选举产生新的 Leader 服务器然后集群中 Follower 服务器开始与新的 Leader 服务器进 行数据同步当集群中超过半数 机器与该 Leader 服务器完成数据同步之后退出恢复模式 进入消息广播模 式Leader 服务器开始接收客户端的事务请求生成事物提案来进行事务请求处理。
假如注册中心挂了消费者还能调⽤服务吗用什么调用的
注册中心对等集群任意一台宕掉后会自动切换到另一台注册中心全部宕掉服务提供者和消费者仍可以通过本地缓存通讯服务提供者无状态任一台 宕机后不影响使用服务提供者全部宕机服务消费者会无法使用并无限次重连等待服务者恢复
dubbo注册中心为什么选择 Zookeeper
可以选 Zookeepermemcachedredis 等。 命名服务服务提供者向 Zookeeper 指定节点写入 url完成服务发布。 负载均衡注册中心承载能力有限而 Zookeeper 集群配合 web 应用很容易达到负载均衡。 zk 支持监听事件特别适合发布/订阅场景dubbo生产者和消费者就类似这场景。 数据模型简单数据存在内存可谓高性能 Dubbo 选择 Zookeeper 作为注册中心的原因有以下几点
分布式特性 Zookeeper 是一个分布式协调服务具有良好的分布式特性和可靠性适合作为 Dubbo 的注册中心。它可以实现分布式服务的注册与发现保证服务的高可用性和一致性。节点管理 Zookeeper 提供了节点管理和监控功能可以轻松管理 Dubbo 微服务架构中的各个节点信息包括服务提供者和消费者的注册信息、健康状态等。顺序一致性 Zookeeper 提供了顺序一致性的特性能够确保节点数据的一致性和可靠性。这对于服务注册中心来说非常重要可以有效避免数据同步的问题。Watcher 机制 Zookeeper 支持 Watcher 机制可以实现对节点变化的监听和通知当服务提供者或消费者状态发生变化时注册中心可以及时感知并通知相关节点。可靠性和稳定性 Zookeeper 是一个经过大规模应用验证的成熟分布式系统具有良好的可靠性和稳定性能够保证 Dubbo 微服务架构的正常运行。社区支持 Zookeeper 拥有活跃的社区和丰富的生态系统可以获得及时的技术支持和更新迭代能够满足 Dubbo 在注册中心方面的需求。 综上所述Zookeeper 作为 Dubbo 的注册中心具有良好的分布式特性、节点管理能力、一致性保证、Watcher 机制、稳定性和社区支持等优势能够很好地满足 Dubbo 微服务架构的需求。因此Dubbo 选择 Zookeeper 作为注册中心是基于以上考虑而做出的合理选择。
关于zookeeper部署的个数
你运行一个zookeeper也是可以的但是在生产环境中你最好部署357个节点。部署的越多可靠性就越高当然只能部署奇数个偶数个是不可以的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一样
Zk分布式锁原理和实现
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 提供了分布式协调的机制可以通过顺序节点实现分布式锁的功能使得分布式系统中的任务可以被协调执行。
zk中的Watch机制的原理
Zookeeper是一个分布式协调组件为分布式架构下的多个应用组件提供了顺序访问控制能力。 它的数据存储采用了类似于文件系统的树形结构以节点的方式来管理存储在Zookeeper上的数据 Zookeeper提供了一个Watch机制可以让客户端感知到Zookeeper Server上存储的数据变化这样一种机制可以让Zookeeper实现很多的场景比如配置中心、注册中心等。 Watch机制采用了Push的方式来实现也就是说客户端和Zookeeper Server会建立一个长连接一旦监听的指定节点发生了变化就会通过这个长连接把变化的事件推送给客户端。 Watch的具体流程分为几个部分 首先是客户端通过指定命令比如exists、get对特定路径增加watch 然后服务端收到请求以后用HashMap保存这个客户端会话以及对应关注的节点路径同时客户端 也会使用HashMap存储指定节点和事件回调函数的对应关系。 当服务端指定被watch的节点发生变化后就会找到这个节点对应的会话把变化的事件和节点信息 发给这个客户端。客户端收到请求以后从ZkWatcherManager里面对应的回调方法进行调用完成事件变更的通知。 ZooKeeper 中的 Watch 机制是一种事件通知机制在节点数据发生变化时可以通知客户端进行相应的处理。以下是 ZooKeeper 中 Watch 机制的原理
注册 Watcher 客户端可以在对节点进行操作比如创建、更新、删除等时通过 API 注册 Watcher 监听这些节点的变化。客户端在注册 Watcher 时需要指定 Watcher 类型比如节点数据变化、子节点列表变化等和具体的节点路径。Watch 持久化存储 当节点数据发生变化时ZooKeeper 会将变化事件保存到内存中并向注册了对应 Watcher 的客户端发送通知客户端接收到通知后会执行相应的回调函数。一次性触发 一旦 Watcher 被触发它就会被删除因此每个 Watcher 只能触发一次。如果客户端需要持续监视节点的变化需要在收到通知后重新注册 Watcher。版本号和序列号 ZooKeeper 使用版本号和序列号来标识节点的状态变化客户端在注册 Watcher 时可以指定观察的节点状态版本号当节点状态发生改变时ZooKeeper 会比较版本号并向注册的 Watcher 发送通知。Watch 事件类型 ZooKeeper 提供了多种 Watch 事件类型包括数据变更通知、子节点列表变更通知等。客户端可以根据需要注册不同类型的 Watcher。 总的来说ZooKeeper 中的 Watch 机制通过注册、通知和回调实现节点状态变化的监听和处理。客户端可以利用 Watch 机制实现对节点数据变化的实时感知并及时作出相应的处理。这种机制在分布式系统中非常重要能够帮助实现实时的状态同步和协调。
Zk实现Leader选举
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 因为网络通信延迟的可能性有可能在新一轮的投票里面收到上一轮投票的票据这种数据应该丢弃否则会影响投票的结果和效率。 zxidzxid越大说明这个节点的数据越接近leader所以用zxid做判断条件是为了避免数据丢失的问题。myid 服务器id这个是避免投票时间过长直接用myid最大值作为快速终结投票的属性。
