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 两阶段提交协议的优化
一阶段提交
当参与者只有一个时,参与者自己就决定了事务提交是否成功,所以可以简化两阶段提交为一阶段提交:
这里的只读事务指的就是查询数据这种操作,在数据库中不是说只有修改数据的操作才能被叫做事务,读取操作也是事务。