Greenplum(三)【分布式事务和两阶段提交协议】

1、事务实现原理和 WAL(单机)

属性含义数据库系统实现
Atomic(原子性)事务中的操作要么全部正确执行,要么完全不执行(要么成功、要么失败)Write Ahead Logging 预写日志,分布式事务:两阶段提交
Consistency(一致性)数据库系统必须保证事务的执行使得数据库从一个一致性状态转移到另一个一致性状态。(满足完整性约束)只要实现了 A、I、D,一致性也就得到了保证 
Isolation(隔离性)多个事务并发执行,并每个事务来说,它并不会感知系统中有其他事务在同时执行多版本并发控制(Multi-Version Concurrency Control)、两阶段锁(Two Phase Commit,2PC)、乐观并发控制(OCC)
Durablity(持久性)一个事务被提交后,该事务对数据库的改变是持久的WAL + 存储管理

DBMS 组成

  •  索引/文件/记录管理器也叫做资源管理器
  • 缓冲区包括 数据页的 buffer pool 以及 log 文件的 buffer
  • 事务的实现需要多个组件协同工作,事务管理器负责协调、调度、跟踪事务的各个执行阶段和状态,还需要通过资源管理器以及日志和恢复模块保证事务的原子性持久性两个属性
  • 并发控制模块通过锁管理器等模块来保证事务的隔离性

存储介质的类型

接下来我们需要了解一下缓冲区,在了解缓冲区之前需要了解一下数据库的存储介质:

包括三大类:

  • 易失性存储器
    • CPU寄存器、Cache、主存等(断电即失)
  • 非易失性存储器
    • Disk、SD、NVM(断电依然存在)
  • 稳定存储器

缓冲区 Buffer Pool

实际上,数据文件是以 page、block 组成的,每个 page 通常是 32K、64K,数据库启动之后会给 Buffer Pool 开启一个特别大的内存空间。我们操作数据的时候其实是把磁盘中的 page 读取到 buffer 中进行操作,完成操作后,再从 buffer 写回到磁盘。这一系列操作可以划分为 4 个步骤:

  • input(page):从磁盘把 page 读进 buffer pool
  • output(page):把 page 更新后刷会磁盘
  • pin(page):不允许 page 刷回到磁盘里,防止在并发操作中,一个 page 被事务 pin 住的时候,其它的事务是不应该把这个 page 刷回到磁盘里的
  • unpin(page):

 Buffer Pool 管理策略

从两个维度来看

  • Force / No-Force
    • Force:事务提交时,所修改的 page 必须强制刷回到持久存储中
    • No-Force:事务提交时,所修改的 page 不需要强制刷回到持久存储中

Force 策略的问题:只要事务提交了,就需要把 buffer pool 里的脏页刷回到磁盘,对持久存储器进行频繁的随机写操作,性能下降。

  • Steal / No-Steal
    • Steal:允许 Buffer Pool 里未提交事务所修改的脏页刷回到持久存储
    • No-Steal:不允许 Buffer Pool 里未提交事务所修改的脏页刷回到持久存储

No-Steal 策略的问题:不允许未提交事务的脏页换出,系统的并发量不高。假如一些事务几乎把整个 buffer pool 里的 page 全都占满了,但是一直没有提交,导致别的事务想空闲 page 去取数据是取不出来的。

所以 Force 和 No-steal 对于面向磁盘的数据库来说是基本不可用的。所以一般我们都会使用 No-Force 和 Steal 这种组合方式来完成数据库缓冲区的管理。

但是虽然 No-Force / Steal 有很好的性能,但是怎么保证事务的原子性和持久性呢?

  • No-Force:事务提交,所修改的数据页没有刷回至持久存储,如果发生断电或系统崩溃(违背了事务的原子性和持久性)
  • Steal:Buffer Pool 中未提交的事务所修改的脏页刷回到持久存储,如果发生断电或者系统崩溃(事务还没有提交呢,违背了事务的原子性)

所以说虽然 No-Force / Steal 有很好的性能,但是不能保证事务的原子性和持久性,那么数据库是怎样解决的呢?

这就引入了日志这种解决方案,来保证事务的原子性和持久性

Logging

  • No-force -> Redo Log
    • 事务提交时,数据页不需要刷回到持久存储,为了保证持久性,先把 Redo Log 写入日志文件。Redo Log 记录修改数据对象的新值(After Image,AFIM)
  • Steal -> Undo Log
    • 允许 Buffer Pool 未提交事务所修改的脏页刷回到持久存储,为了保证原子性,先把 Undo Log 写入日志文件。Undo Log 记录了修改对象的旧值(Before Image,BFIM)

缓冲区管理策略和事务恢复的关系

对于右上角的 No-Force 和 No-steal 组合来说,性能是最好的,但是恢复是最差的,因为它既要做 Redo Log 又要做 Undo Log。相反地,对于左下角的 Force 和 No-Steal 来说,性能是最差的,但是恢复是最快的。

所以不同的 Buffer Pool 管理策略和更新方式决定了数据库的恢复策略。

Buffer Pool 和 Log Pool

通过日志这种机制,可以把对数据库文件的随机的写操作,变成了顺序的写操作,因为对日志的操作是append的方式进行操作的,buffer 满了或者需要commit 事务的时候才把 log buffer 刷回到磁盘,这样就极大地提高了数据库的性能。

Write Ahead Logging

第一点,任何被修改的 page 在刷回到磁盘之间,必须保证 log 先写入磁盘

第二,确保事务对数据修改的 log 写入到磁盘之后,事务才能提交

2、PostgreSQL 和 Greenplum 采用的策略

Steal + No-Force 对于一个硬盘数据库是最好的,这也是PostgreSQL 和 Greenplum 采用的策略

这就有了一个问题,PG 里只有 redo log,没有 undo log,事务回滚的时候不需要 undo 操作

这是因为 PG 采用的是 MVCC ,它的更新操作不是 in-place update ,而是重新创建 tuple,所以已经有了 tuple 的旧值,就不需要再去通过 undo log 去记录这些旧值了。

  • MySQL 同样采用 MVCC 模式的数据去进行并发控制,但为什么 MySQL 事务恢复的时候就需要 undo log?

版本存储(Version Storge)

可以看到,对于 PGSQL 来说,当对数据修改时,会直接在原表上追加数据,让被修改的数据通过指针指向新的数据(tuple)上。

而对于 MySQL/Oracle 来说,虽然也采用 MVCC ,但是它们的 Version Storage 采用的是另一种实现方式。也就是把数据的差异变化记到一个 delta storge 中,形成一个链表,也叫做回滚段(rollback segment)。

2 PC

这里 2PC 和下面的 ZAB协议参考自这里 

2PC,是Two-Phase Commit的缩写,即二阶段提交,是计算机网络尤其是在数据库领域内,为了使基于分布式系统架构下的所有节点在进行事务处理过程中能够保持原子性和一致性而设计的一种算法。通常,二阶段提交协议也被认为是一种一致性协议,用来保证分布式系统数据的一致性。目前,绝大部分的关系型数据库都是采用二阶段提交协议来完成分布式事务处理的,利用该协议能够非常方便地完成所有分布式事务参与者的协调,统一决定事务的提交或回滚,从而能够有效地保证分布式数据一致性,因此二阶段提交协议被广泛地应用在许多分布式系统中。

一阶段:提交事务请求

1、事务询问

协调者向所有的参与者发送事务内容,询问是否可以执行事务提交操作,并开始等待各参与者的响应。

2、执行事务

各参与者节点执行事务操作,并将Undo和Redo信息记入事务日志中。

3、参与者向协调者反馈

如果各参与者成功执行了事务操作,那么就反馈给协调者Yes响应,表示事务可以执行;如果参与者没有成功执行事务,那么就反馈给协调者No响应,表示事务不可以执行。

二阶段:执行事务提交

事务提交

协调者接收到所有参与者的ACK消息都是YES,执行事务提交

1、发送提交申请

协调者给参与者发出Commit请求

2、事务提交

参与者收到Commit请求后,执行事务提交,完成后释放整个事务执行期间占用的事务资源

3、反馈结果

参与者在完成事务提交后,给协调者发送ACK消息

4、事务完成

协调者接收到所有参与者反馈的ACK消息后,事务完成

事务中断

任何一个参与者反馈了NO,或者等待超时了导致协调者没有接收到所有参与者的反馈就会中断事务

1、发送回滚请求

协调者向所有参与者发送Rollback请求

2、事务回滚

参与者接收到Rollback请求后,会根据一阶段中的Undo日志进行事务回滚,

3、事务回滚结果反馈

参与者在完成回滚后,向协调者发送ACK消息

4、中断事务

协调者接收到所有参与者反馈的ACK消息后完成事务中断

ZAB 协议

Zookeeper 是通过 Zab 协议来保证分布式事务的最终一致性

ZAB又名原子广播协议(Zookeeper Atomic Broadcast ) 作用在可用状态,有Leader时

原子:要么成功,要么失败,没有中间状态(FIFO队列+类似2PC操作)

广播:分布式多节点的,所以执行操作都是由Leader(协调者)向所有Follower(参与者)统一发送请求

PS:

ZK的数据状态存储在内存

ZK是日志存储在磁盘

  • 第一步:在ZK客户端对任意一个Follower节点执行一个写操作create /rhys "aaa"
  • 第二步:Follower节点将这笔写操作转发给Leader节点
  • 第三步:Leader会创建一个事务ID(zxid),假设本次给出的事务ID为1
  • 第四步:其实在Leader对于每个Follower都维护着一个发送队列(FIFO队列),紧接着Leader会给两台Follower发起关于创建XXX节点这件事的第一阶段操作写日志,那么这个写日志操作就会先入发送队列。再顺序执行队列中操作,当写日志操作执行成功后,Follower会返回一个ok/yes的状态,那对应的Leader中也会生成一个ok/yes的状态,由于我们是一主两从,那有了两台机返回了ok状态,满足了过半通过条件 (3/2+1),这时Leader会再次对两台Follower发起第二阶段write写内存操作,其实就是类似两阶段提交(2PC),只是这里的两阶段提交和开始回顾的两阶段提交不一样的地方时没有中断事务操作,因为这里的两阶段提交不需要接收到所有Follower(参与者)的ACK反馈,只需要超过一半的机器ACK就可以了,依然是入发送队列,然后从队列中顺序执行操作,操作完成同样的会返回一个ok/yes状态,达到过半条件则Leader会给Follower返回一个over-ok状态,再由Follower传递给客户端

这边有一点需要提一下,我们刚提到过半提交这个概念对吧,那另一台Follower机器没有返回ok状态,对应的发送队列依旧会放入一个write操作,只要最终那台没有返回ok的Follower机器能把队列中操作消费完,那这个节点的数据最终还是会跟其他两个节点保持一致的,这边就体现出了最终一致性。

总结:回过头再看ZAB的原子没有中间状态其实就是依据FIFO队列+类似2PC操作,广播其实就是体现了过半通过的概念

ZAB协议(Zookeeper Atomic Broadcast)是Zookeeper分布式协调服务中用于保证数据一致性的核心协议。它之所以被描述为“没有中间状态(2PC+FIFO),只有成功和失败”,这主要源于其设计原理和实现机制。以下是对这一说法的详细解释:

1. 类似2PC但移除了中断逻辑

**二阶段提交(2PC, Two-Phase Commit)**协议通常包含两个阶段:准备阶段(Prepare)和提交阶段(Commit)。在准备阶段,协调者会询问参与者是否可以执行事务,参与者如果同意则进行预提交并锁定资源;在提交阶段,如果所有参与者都同意提交,则协调者会发送提交命令,否则发送回滚命令。然而,2PC协议存在事务中断的风险,即任何一个参与者反馈了NO或等待超时,都会导致事务中断。

ZAB协议的广播模式则类似于一个移除了中断逻辑的2PC协议。在ZAB中,Leader(协调者)在收到写请求后,会为其分配一个ZXID(事务ID)并生成提案发送给所有Follower(参与者)。Follower在接收到提案后,首先将其写入本地日志但不提交,成功写入后返回ACK给Leader。当Leader收到过半Follower的ACK响应后,会发出commit请求执行提交。这里的关键是,ZAB协议移除了中断逻辑,即使有部分Follower因为网络延迟或故障未能及时响应,也不会导致整个事务中断。只要过半的Follower成功响应,事务就会被认为成功,剩余的Follower则会在后续的数据同步阶段与集群达成一致。

2. FIFO队列保证顺序性

ZAB协议通过为每个Follower维护一个FIFO(先进先出)队列来保证事务的顺序性。Leader会将需要广播的提案依次放入到每个Follower的队列中,并按照队列中的顺序执行操作。这种机制确保了即使在网络延迟或故障的情况下,Follower最终也能按照正确的顺序执行事务,从而实现最终一致性。

3. 成功和失败状态

由于ZAB协议移除了中断逻辑,并采用了FIFO队列来保证顺序性,因此事务的执行结果只有两种状态:成功或失败。成功状态意味着事务已经被过半的Follower成功执行并提交;失败状态则通常发生在Leader选举失败或无法与过半的Follower通信时,此时整个集群会进入恢复模式,直到选举出新的Leader并完成数据同步。

综上所述,ZAB协议通过类似但移除了中断逻辑的2PC协议和FIFO队列机制,实现了事务的原子性和顺序性,同时保证了事务的执行结果只有成功和失败两种状态。这种设计使得Zookeeper能够在分布式环境下提供高可靠性和高性能的数据一致性服务。

 3、分布式事务和两阶段提交的原理

一阶段提交协议

 分布式事务的原子性要求事务中的操作要么全部成功、要么全部失败。上面的一阶段提交明显不能保证。

两阶段提交协议

在两阶段提交中,任意参与者如果回复 no,则该事务不能被提交。

两阶段提交与日志操作

两阶段提交协议可能会产生阻塞:

1、资源锁定(参与者在 prepare 之后,在抽到 commit 之前故障了)

在准备阶段(Prepare phase),参与者需要执行事务但不提交,同时保留对事务的修改。这意味着在参与者投票Prepared之后,在接收到Commit之前,资源会处于被锁状态。如果因为网络中断、协调者故障等原因导致长时间无法收到Commit或Abort指令,这些资源将一直被锁定,无法被其他事务使用,从而导致系统性能下降。

关于这一点,PGSQL 有自己的恢复机制(下面写了)。

2、参与者阻塞

在参与者投票Prepared后,如果协调者因为某种原因(如故障)无法发送Commit或Abort指令,参与者将处于阻塞状态,无法继续执行其他操作。这种情况在协调者发起COMMIT之后尤为严重,因为所有参与者都在等待协调者的最终指令,而协调者的故障将导致所有参与者都无法完成事务。

两阶段提交协议需要处理的故障

4、Greenplum 两阶段提交协议的实现

Greenplum 是基于 PGSQL ,所以我们先看一下 PGSQL 的两阶段提交:

所以,PGSQL 是通过 prepare transaction、commit prepared 和 rollback prepared 三个语句完成对分布式事务两阶段提交协议的支持。

Greenplum 实现分布式事务与并发控制

Greenplum 的两阶段提交函数调用关系

5、Greenplum 两阶段提交协议的优化

一阶段提交

当参与者只有一个时,参与者自己就决定了事务提交是否成功,所以可以简化两阶段提交为一阶段提交:

这里的只读事务指的就是查询数据这种操作,在数据库中不是说只有修改数据的操作才能被叫做事务,读取操作也是事务。 

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/web/42517.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

【删库跑路】一次删除pip下载的所有第三方库方法

进入命令行,先list看下库存 pip list导出所有的第三方库至一文件列表 pip freeze >requirements.txt按照列表卸载所有库 pip uninstall -r requirements.txt -y再list看下,可见库存已清空

1、课程导学(react+区块链实战)

1、课程导学(react区块链实战) 1,课程概述(1)课程安排(2)学习前提(3)讲授方式(4)课程收获 2,ibloackchain(1)安…

java:字符缓冲流特有功能

BufferedWriter: void newLine():写一行行分隔符,行分隔符字符串由系统属性定义 BufferedReader: public String readLine():读一行文字,结果包含行的内容的字…

AI赋能OFFICE 智能化办公利器!

ONLYOFFICE在线编辑器的最新版本8.1已经发布,整个套件带来了30多个新功能和432个bug修复。这个文档编辑器无疑成为了办公软件中的翘楚。它不仅支持处理文本文档、电子表格、演示文稿、可填写的表单和PDF,还允许多人在线协作,并支持AI集成&…

哪些独立站外链策略最有效?

在当前的SEO领域中,独立站外链策略的效果差异很大,但GPB外链无疑是其中最为有效的一种。GPB外链,指的是通过高质量、包收录且dofollow的顶级域名独立站来获得外链,这种外链策略能够显著提升目标网站的整体排名数据。 关键词排名的…

redis学习(007 实战:黑马点评:登录)

黑马程序员Redis入门到实战教程,深度透析redis底层原理redis分布式锁企业解决方案黑马点评实战项目 总时长 42:48:00 共175P 此文章包含第25p-第p34的内容 文章目录 短信登录功能session 共享问题 短信登录功能 接口编写 这里是Result的封装 过滤器在拦截器的外层…

嵌入式系统中的实时操作系统任务调度策略

嵌入式系统中的实时操作系统任务调度策略 在嵌入式系统中,实时任务调度是确保系统响应性和稳定性的关键方面之一。不同的任务调度策略可以影响系统的性能和实时性。本文将深入探讨两种常见的实时任务调度策略:固定优先级调度和循环时间片调度&#xff0…

mysql查询语句执行流程

流程图 连接器:建立连接,管理连接、校验用户身份;查询缓存:查询语句如果命中查询缓存则直接返回,否则继续往下执行。MySQL 8.0 已删除该模块;解析 SQL,通过解析器对 SQL 查询语句进行词法分析、…

阿尔泰科技与西安交通大学陕西省某技术重点实验室共谋未来!

近日,阿尔泰科技的电子工程师(熊工)应邀前往西安交通大学陕西省某技术重点实验室,参与课题组项目的测试与调试工作。此次合作不仅成功推动了项目的进展,还为未来的深入合作奠定了坚实基础。 阿尔泰科技作为领先的测控技…

基于SpringBoot构造超简易QQ邮件服务发送(分离-图解-新手)

目录 获取QQ 授权码 SpringBoot构建 依赖 Yaml配置 服务编写 测试 获取QQ 授权码 https://mail.qq.com/ 接着后就会有对应的密钥了 SpringBoot构建 依赖 这里的建议是 2.0系列的Springboot版本用低一点的邮件依赖 <!-- 电子邮件 --> <dependency>&…

物联网实战:STM32+ESP8266温湿度数据采集上传Linux服务器与数据库可视化(附代码示例)

摘要: 本文将手把手教你搭建一个完整的物联网数据监控平台&#xff0c;使用STM32采集温湿度数据&#xff0c;通过ESP8266 WiFi模块上传至Linux服务器&#xff0c;并利用Python脚本将数据存储到MySQL数据库&#xff0c;最后实现每日平均值的计算和可视化展示。 关键词: STM32, …

抖音本地生活火爆!普通人如何申请抖音本地生活服务商?

当前&#xff0c;随着抖音外卖的正式开放&#xff0c;抖音本地生活的热度也迎来了新的高潮&#xff0c;与抖音本地生活服务商怎么申请等话题相关的词条更是成为了多个创业者社群的热搜榜单的常客。 事实上&#xff0c;就抖音本地生活服务商怎么申请等问题本身而言&#xff0c;…

nvm安装报错(镜像问题)

一、问题报错 安装的时候如果跟着网上早些时候的配置&#xff0c;调整了setting文件&#xff0c;配置镜像的话&#xff0c;可能报这个错误。 这个是因为他没检索到后面的链接地址&#xff0c;因为镜像的地址新的已经更换了。使用这个吧&#xff1a; node_mirror: https://npm…

java基础01—根据源码分析128陷阱以及如何避免128陷阱

源码分析128陷阱 如上图所示&#xff0c;int类型数据超过127依旧能正常比较&#xff0c;但Integer类型就无法正确比较了 /*** Cache to support the object identity semantics of autoboxing for values between* -128 and 127 (inclusive) as required by JLS.** The cache …

视频监控管理平台智能边缘分析一体机视频监控系统客流统计检测算法

在当今数据驱动的时代&#xff0c;客流统计作为商业分析的重要手段&#xff0c;其准确性和实时性对于商家决策具有至关重要的影响。随着技术的发展&#xff0c;智能边缘分析一体机结合了边缘计算与深度学习技术&#xff0c;为客流统计提供了更为高效、精准的解决方案。 首先&am…

美容师有什么话术技巧?美业人如何提升自己的销售技巧?博弈美业门店管理系统分享经验

作为一名美容师&#xff0c;有一些话术和销售技巧可以帮助你提升服务质量和销售业绩。以下是博弈美业收银系统分享的一些建议&#xff1a; 1.建立信任&#xff1a; 在与客户交流时&#xff0c;表现出真诚、友好和专业的态度。倾听客户的需求&#xff0c;并给予针对性的建议&a…

跟我练习100道FPGA入门题目~(2/100)

难度指数&#xff1a;一颗星 关键词&#xff1a;组合逻辑、入门基础 点击此处直接答题&#xff1a;F学社-全球FPGA技术提升平台 (zzfpga.com) 提交代码就能看到波形图和电路图啦&#xff01; &#xff08;在社区加入群聊&#xff0c;更多学友等着和你探讨~&#xff09;

CTF-PWN-kernel-前置

文章目录 打包上传测试脚本检查保护调试脚本编写Intel Syntax特点:示例: AT&T Syntax特点:示例: 对比总结 c库中asm的汇编 用到啥更新啥&#xff0c;一直更新ing 打包上传测试脚本 #!/bin/sh gcc expolit.c -static -masmintel -g -o expolit mv expolit fs/ cd core find…

淮北在选择SCADA系统时,哪些因素会影响其稳定性?

关键字:LP-SCADA系统, 传感器可视化, 设备可视化, 独立SPC系统, 智能仪表系统,SPC可视化,独立SPC系统 在选择SCADA系统时&#xff0c;稳定性是一个关键因素&#xff0c;因为它直接影响到生产过程的连续性和安全性。以下是一些影响SCADA系统稳定性的因素&#xff1a; 硬件质量…

微服务-初级篇

微服务-初级篇 认识微服务1.1 单体架构1.2 分布式架构1.3 微服务 SpringCloud2.1 了解2.2 服务拆分原则2.3 服务拆分效果 Nacos注册中心3.1 认识和安装Nacos3.1.1 Nacos下载3.1.2 Nacos安装 3.2 服务注册到Nacos Feign远程调用4.1 Feign引入4.2 Feign配置 认识微服务 1.1 单体…