Zookeeper学习系列【三】Zookeeper 集群架构、读写机制以及一致性原理(ZAB协议)

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
简介: Zookeeper学习系列【三】Zookeeper 集群架构、读写机制以及一致性原理(ZAB协议)


本篇的内容主要包含以下几点:

  • Zookeeper 集群架构
  • Zookeeper 读写机制
  • ZAB协议
  • 关于Zookeeper 集群的一些其他讨论
  • Zookeeper(读性能)可伸缩性 和 Observer节点
  • Zookeeper 与 CAP 理论
  • Zookeeper 作为 服务注册中心的局限性

一、Zookeeper 集群架构

接下来我们来说一说Zookeeper的集群架构。

Zookeeper 集群中的角色

第一章提过,Zookeeper中,能改变ZooKeeper服务器状态的操作称为事务操作。一般包括数据节点创建与删除、数据内容更新和客户端会话创建与失效等操作

  • Leader 领导者 :Leader 节点负责Zookeeper集群内部投票的发起和决议(一次事务操作),更新系统的状态;同时它也能接收并且响应Client端发送的请求。
  • Learner 学习者
  • Follower 跟随者 : Follower 节点用于接收并且响应Client端的请求,如果是事务操作,会将请求转发给Leader节点,发起投票,参与集群的内部投票,
  • Observer 观察者:Observer 节点功能和Follower相同,只是Observer 节点不参与投票过程,只会同步Leader节点的状态。
  • Client 客户端

Zookeeper 通过复制来实现高可用。在上一章提到的集群模式(replicated mode)下,以Leader节点为准,Zookeeper的ZNode树上面的每一个修改都会被同步(复制)到其他的Server 节点上面。

上面实际上只是一个概念性的简单叙述,在看完下文的读写机制ZAB协议的两种模式之后,你就会对这几种角色有一个更加深刻的认识。

二、Zookeeper 读写机制

读写流程

下图就是集群模式下一个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 节点会认为这次写请求处理成功了,提交本次的事务。

乐观锁

Zookeeper 的核心思想就是,提供一个非锁机制的Wait Free 的用于分布式系统同步的核心服务。其核心对于文件、数据的读写服务,并不提供加锁互斥的服务

但是由于Zookeeper的每次更新操作都会更新ZNode的版本(详见第一章),也就是客户端可以自己基于版本的对比,来实现更新数据时的加锁逻辑。例如下图。

就像我们更新数据库时,会新增一个version字段,通过更新前后的版本对比来实现乐观锁。

三、ZAB协议

终于到了ZAB协议,讲述完ZAB协议,大家对Zookeeper的一些特性会有更深的体会,对本文的其他内容也会有更透彻的理解。

ZAB 协议是为分布式协调服务ZooKeeper专门设计的一种支持崩溃恢复一致性协议,这个机制保证了各个server之间的同步。全称 Zookeeper Atomic Broadcast Protocol - Zookeeper 原子广播协议。

两种模式

Zab协议有两种模式,它们分别是恢复模式广播模式

广播模式

广播模式类似于分布式事务中的 Two-phase commit (两阶段式提交),因为Zookeeper中一次写操作就是被当做一个事务,所以这实际上本质是相同的。

广播模式,一次写请求要经历以下的步骤

  1. ZooKeeper Server接受到Client的写请求
  2. 写请求都被转发给Leader节点
  3. Leader节点先将更新持久化到本地
  4. Leader节点将此次更新提议(propose)给Followers,进入收集选票的流程
  5. Follower节点接收请求,成功将修改持久化到本地,发送一个ACK给Leader
  6. Leader接收到半数以上的ACK时,Leader将广播commit消息并在本地deliver该消息。
  7. 当收到Leader发来的commit消息时,Follower也会deliver该消息。

广播协议在所有的通讯过程中使用TCP的FIFO信道,通过使用该信道,使保持有序性变得非常的容易。通过FIFO信道,消息被有序的deliver。只要收到的消息一被处理,其顺序就会被保存下来。

但是这种模式下,如果Leader自身发生了故障,Zookeeper的集群不就提供不了写服务了吗?这就引入了下面的恢复模式。

恢复模式

简单点来说,当集群中的Leader故障或者服务启动的时候,ZAB就会进入恢复模式,其中包括Leader选举和完成其他Server和Leader之间的状态同步

NOTE:选主是ZAB协议中最为重要和复杂的过程。这里面的概念知识较多,放在本章一起讲反而不利于理解本章的知识,所以我打算在下一章单独介绍,同学们可以选择性地食用。

关于Zookeeper 集群的一些其他讨论

1. Zookeeper(读性能)可伸缩性 和 Observer节点

一个集群的可伸缩性即可以引入更多的集群节点,来提升某种性能。Zookeeper实际上就是提供读服务和写服务。在最早的时候,Zookeeper是通过引入Follower节点来提升读服务的性能。但是根据我们之前学习过的读写机制和ZAB协议的内容,引入新的Follower节点,会造成Zookeeper 写服务的下降,因为Leader发起的投票是要半数以上的Follower节点响应才会成功,你Follower多了,就增加了协议中投票过程的压力,可能会拖慢整个投票响应的速度。结果就是,Follower节点增加,集群的写操作吞吐会下降

在这种情况下,Zookeeper 在3.3.3版本之后,在集群架构中引入了Observer角色,和Follower唯一的区别的就是不参与投票不参与选主。这样既提升了读性能,又不会影响写性能。

另外提一句,Zookeeper的写性能是不能被扩展的,这也是他不适合当做服务注册发现中心的一个原因之一,在服务发现和健康监测场景下,随着服务规模的增大,无论是应用频繁发布时的服务注册带来的写请求,还是刷毫秒级的服务健康状态带来的写请求,都会Zookeeper带来很大的写压力,因为它本身的写性能是无法扩展的。后文引的文章会详细介绍。

2. Zookeeper 与 CAP 理论

分布式领域中存在CAP理论:

  • C:Consistency,一致性,数据一致更新,所有数据变动都是同步的。
  • A:Availability,可用性,系统具有好的响应性能。
  • P:Partition tolerance,分区容错性。以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择,也就是说无论任何消息丢失,系统都可用。

CAP 定理的含义 -- 阮一峰

该理论已被证明:任何分布式系统只可同时满足两点,无法三者兼顾。 因此,将精力浪费在思考如何设计能满足三者的完美系统上是愚钝的,应该根据应用场景进行适当取舍。

根据我们前面学习过的读写机制和ZAB协议的内容,Zookeeper本质应该是一个偏向CP的分布式系统。因为广播协议本质上是牺牲了系统的响应性能的。另外从它的以下几个特点也可以看出。也就是在第一章最后提出的几个特点。

① 顺序一致性 从同一个客户端发起的事务请求,最终将会严格按照其发起顺序被应用到ZooKeeper中。

② 原子性 所有事务请求的结果在集群中所有机器上的应用情况是一致的,也就是说要么整个集群所有集群都成功应用了某一个事务,要么都没有应用,一定不会出现集群中部分机器应用了该事务,而另外一部分没有应用的情况。

③ 单一视图 无论客户端连接的是哪个ZooKeeper服务器,其看到的服务端数据模型都是一致的。

④ 可靠性 一旦服务端成功地应用了一个事务,并完成对客户端的响应,那么该事务所引起的服务端状态变更将会被一直保留下来,除非有另一个事务又对其进行了变更。

3. Zookeeper 作为 服务注册中心的局限性

直接引一篇阿里中间件的文章吧,讲的比我好。实际在生产情况下,大多数公司没有达到像大公司那样的微服务量级,Zookeeper是完全能满足服务注册中心的需求的。

阿里巴巴为什么不用 ZooKeeper 做服务发现?



相关实践学习
基于MSE实现微服务的全链路灰度
通过本场景的实验操作,您将了解并实现在线业务的微服务全链路灰度能力。
目录
打赏
0
1
0
0
93
分享
相关文章
深入解析Tiktokenizer:大语言模型中核心分词技术的原理与架构
Tiktokenizer 是一款现代分词工具,旨在高效、智能地将文本转换为机器可处理的离散单元(token)。它不仅超越了传统的空格分割和正则表达式匹配方法,还结合了上下文感知能力,适应复杂语言结构。Tiktokenizer 的核心特性包括自适应 token 分割、高效编码能力和出色的可扩展性,使其适用于从聊天机器人到大规模文本分析等多种应用场景。通过模块化设计,Tiktokenizer 确保了代码的可重用性和维护性,并在分词精度、处理效率和灵活性方面表现出色。此外,它支持多语言处理、表情符号识别和领域特定文本处理,能够应对各种复杂的文本输入需求。
68 6
深入解析Tiktokenizer:大语言模型中核心分词技术的原理与架构
MySQL原理简介—2.InnoDB架构原理和执行流程
本文介绍了MySQL中更新语句的执行流程及其背后的机制,主要包括: 1. **更新语句的执行流程**:从SQL解析到执行器调用InnoDB存储引擎接口。 2. **Buffer Pool缓冲池**:缓存磁盘数据,减少磁盘I/O。 3. **Undo日志**:记录更新前的数据,支持事务回滚。 4. **Redo日志**:确保事务持久性,防止宕机导致的数据丢失。 5. **Binlog日志**:记录逻辑操作,用于数据恢复和主从复制。 6. **事务提交机制**:包括redo日志和binlog日志的刷盘策略,确保数据一致性。 7. **后台IO线程**:将内存中的脏数据异步刷入磁盘。
112 12
Git进阶笔记系列(01)Git核心架构原理 | 常用命令实战集合
通过本文,读者可以深入了解Git的核心概念和实际操作技巧,提升版本管理能力。
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
101 3
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
379 69
从单体到微服务:如何借助 Spring Cloud 实现架构转型
智慧工地云平台的技术架构解析:微服务+Spring Cloud如何支撑海量数据?
慧工地解决方案依托AI、物联网和BIM技术,实现对施工现场的全方位、立体化管理。通过规范施工、减少安全隐患、节省人力、降低运营成本,提升工地管理的安全性、效率和精益度。该方案适用于大型建筑、基础设施、房地产开发等场景,具备微服务架构、大数据与AI分析、物联网设备联网、多端协同等创新点,推动建筑行业向数字化、智能化转型。未来将融合5G、区块链等技术,助力智慧城市建设。
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
122 1
服务架构的演进:从单体到微服务的探索之旅

热门文章

最新文章