郑州营销型网站制作策划,画册设计一般用什么软件,邢台哪儿专业做网站,西安网站推广1. 什么是事务#xff1f;
应用在运行时可能会发生数据库、硬件的故障#xff0c;应用与数据库的网络连接断开或多个客户端端并发修改数据导致预期之外的数据覆盖问题#xff0c;为了提高应用的可靠性和数据的一致性#xff0c;事务应运而生。
从概念上讲#xff0c;事务…1. 什么是事务
应用在运行时可能会发生数据库、硬件的故障应用与数据库的网络连接断开或多个客户端端并发修改数据导致预期之外的数据覆盖问题为了提高应用的可靠性和数据的一致性事务应运而生。
从概念上讲事务是应用程序将多个读写操作组合成一个逻辑单元的一种形式这样其中所有的读写操作都被视为单个操作来执行要么成功提交要么失败回滚不存在任何部分成功和部分失败的情况。现在几乎所有的关系型数据库和一些非关系型数据库都支持事务。
1.1 ACID
事务通过ACID来保证安全的操作它们分别是原子性Atomicity、一致性Consistency、隔离性Isolation和持久性Durability。ACID的提出旨在为数据库容错机制建立精确的术语但是它在不同的数据库中实现并不相同我们来对其逐一的进行解释。
原子性
原子性定义的特征是一个事务必须被视为一个不可分割的工作单元整个事务中的所有操作要么全部提交成功要么全部失败回滚不可能只执行其中的一部分操作。 一致性
一致性在ACID中是“多余的”存在它不同于原子性、隔离性和持久性一致性是应用程序的属性而其他三者是数据库的属性。应用可能依赖原子性和隔离性来保证一致性但有时候一致性的保证并不仅仅取决于数据库。
一致性的体现依赖应用程序对数据的约束比如在会计系统中所有账户的交易收支一定是平衡的。如果一个事务开始于一个平衡状态那么在该事务执行完成提交后那么依然会保持平衡。从概念上来说一致性是对数据的一组特定约束必须始终成立这一点由应用程序来保证因为这些写入和修改的逻辑都是由应用程序决定的数据库只负责对这些操作进行执行。 隔离性
在实际工作中大多数数据库都同时被多个客户端访问这就可能会发生客户端并发修改同一条数据的情况引发并发问题。如下图中例子所示 User1和User2要同时在数据库中操作计数器增长每个用户都是先读取值执行加1然后写入。理论上计数器的值最终应该为44但是由于并发问题使得终值为43。
通常来说隔离性让一个事务所做的修改在最终提交以前对其他事务不可见它解决的是并发问题。如果一个事务进行多次写入则另一个事务要么看到全部写入结果要么什么都看不到。所以在上述例子中User2在修改计数器时读取到的值应该是User1修改完之后的结果43之后执行加1使得最终结果为44。 持久性
持久性是一个承诺即事务成功提交即使发生硬件故障或者数据库崩溃写入的任何数据都不会丢失在单节点数据库中它通常意味着数据已经被写入硬盘或SSD在多节点数据库中持久性可能意味着数据已经成功复制到一些节点。但是如果硬盘和备份被销毁那么显然没有任何数据库能再找回这些数据所以完美的持久性并不存在。
2. 并发产生数据不一致的问题
往往由于事务之间的操作对象有竞争关系并且又因为并发事务之间不确定的时序关系会导致这些所操作的有竞争关系的对象会出现各种奇怪的结果下面我们就来看看这些常见的问题。
2.1 脏写
两个事务尝试同时更新数据库中相同的对象如果先前的写入是尚未提交事务的一部分后面的写入将一个尚未提交的值覆盖掉了这种情况被称为脏写。
2.2 脏读
如果A事务已经将一些数据写入数据库但是A事务还没有提交或中止现在开启另一个B事务查询那么B事务能看到A事务中没有提交的数据这就是脏读。
我们考虑一种情况一旦A事务发生回滚B事务很有可能将未提交过的数据提交给数据库因此造成的问题会让人无从下手去排查。
2.3 不可重复读
我们拿一个例子来说Alice 在银行有 1000 美元的储蓄分为两个账户每个 500 美元。现在有一个事务从她的一个账户转移了 100 美元到另一个账户。如果她在事务处理的过程中查看其账户余额她可能在发出转账之后看到付款账户的余额为 400 美元而收款账户的余额仍为 500 美元。对 Alice 来说现在她的账户看起来总共只有 900 美元转账的 100 美元似乎凭空消失了而再对收款账户进行读取时发现余额变成了 600 美元。
这种情况被称为不可重复读又被称为读偏差即对同一数据两次读取的结果不一致。
2.4 丢失更新
两个事务同时执行读取-修改-写入序列其中一个写操作在没有合并另一个写操作变更的情况下直接覆盖了另一个写操作的结果导致了数据的丢失这种情况被称为丢失更新。
比较直接的避免丢失更新的方法是不使用读取-修改-写入这一系列操作而是进行原子更新以计数器为例SQL如下。它的原理通常是获取要读取对象的排他锁使得事务在修改同一数据时依次执行。
update counters set value value 1 where key 1;
如果不能避免读取-修改-写入这一系列操作那么可以通过显式加锁FOR UPDATE的方式来避免丢失更新使得任何其他想要读取同一对象的事务被阻塞直到第一个获取到该锁的事务执行完毕。
BEGIN TRANSACTION;SELECT * FROM xxx FOR UPDATE;-- 执行业务逻辑
UPDATE xxx SET ...;COMMIT;
比较并设置CAS是一种比较常见的乐观的避免丢失更新的操作。当对数据更新时会将数据表中的值和读取值进行对比只有在没有发生改变的情况下才允许更新否则需要重试这个事务。一般在工作中会采用在数据表中添加时间戳列的方式来实现CAS。
2.5 幻读和写入偏差问题
幻读用一句话来概括就是一个事务的写入改变了另一个事务的搜索查询结果。
A事务的select查询出符合条件的数据并检查是否符合业务要求根据检查结果决定业务是否继续执行。如果此时B事务对数据进行修改并符合A事务select的查询条件那么A事务在执行完写入操作后再次执行select查询会发现不同的结果这很可能会导致写入偏差问题。
写入偏差问题是两个事务读取相同的对象然后更新其中一些对象时发生了预期之外的异常情况。它区别于脏写和丢失更新因为它是两个事务正在更新两个不同的对象。如下面这个例子所示Alice 和 Bob 是两位值班医生两人都感到不适所以他们都决定请假。不幸的是他们恰好在同一时间点击按钮下班 这导致了没有医生值班违反了至少有一名医生值班的业务要求。
解决写入偏差问题比较麻烦因为它涉及多个对象采用单对象原子操作的方法不能解决。通常情况下会采用更改隔离级别为可串行化或通过加锁的方式来解决。
但是加锁的方式并不是在所有情况下都适用。比如多人预定同一时段的会议室因为该时段的会议室预定记录还没有生成导致多人读取预定纪录时都没有读到对应的结果值所以就无从加锁那么此时将会造成多人预定同一时段会议室的结果。为了解决这种情况可以再创建一张数据表管理会议室的时间段当有人想预定某时段会议室时会将该时段的数据进行加锁那么这时再有其他用户来查询时将会被阻塞这种方法被称为物化冲突。
3. 隔离级别
数据库一直试图通过事务隔离解决并发问题。可串行化隔离级别能保证事务串行执行这意味着不会发生并发问题。但是在实际生产中为了保证系统的性能往往不会采用该隔离级别而是会采用一些较弱的隔离级别它们可能在某些情况下不能保证数据的一致性但是能够让系统的性能更好。下面我们对这些隔离级别进行介绍
3.1 读未提交
该隔离级别相对更弱只能避免脏写。
3.2 读已提交Read Committed
这种隔离级别非常流行它能够避免脏读和脏写。
最常见的情况是使用行锁来防止脏写当事务想要修改同一个对象时则必须等到第一个事务提交或回滚后才能获取该行的锁继续。
脏读也可以通过加读锁来避免但是这种方式会导致在有长时间的写入事务持有要读数据的锁时读请求被阻塞所以这种方式在实践中的效果并不好。另一种避免方式是数据库将已经写入的旧值记住即使发生新的写入事务且并没有执行完时读请求读取到的都是这个旧值只有当该写事务提交时才能读取到新值。
3.3 可重复读
可重复读能够避免脏写、脏读、不可重复读和只读查询中的幻读快照隔离是实现可重复读的常见解决方案。每个事务都从数据库的一致性快照中进行读取那么这也就意味着该事务能看到事务开始时在数据库中提交的所有数据。即使这些数据随后被新的事务更改该事务还仍然读取的是在事务开始时的旧数据。这种办法对长时间运行的只读查询非常有用因为如果在查询过程中数据不断的变化那么没有办法对数据进行分析。 不提供快照隔离的读已提交不能实现可重复读因为它只记住了数据的两个版本。 快照隔离也是通过写锁的方式来避免脏写而避免脏读的方式无需加锁而是通过读取数据库中维护的对应版本的数据对象它的关键原则是读不阻塞写写不阻塞读。这也就意味着数据库在处理一致性快照上的长时间查询时能够同时处理写入而不会发生锁的争用。 使用InnoDB引擎的MySQL对快照隔离的实现方法是MVCC多版本并发控制它会同时维护单个对象的多个版本以提供多个不同时间节点的数据状态我们下面来简单地看一下它的实现原理。
对于InnoDB引擎的表来说它的聚簇索引记录中都包含两个必要的隐藏列trx_id和roll_pointer
trx_id: 事务每次对某条聚簇索引记录进行改动时都会把该事务的事务ID赋值给 trx_idroll_pointer: 每次对某条聚簇索引记录进行改动时都会把旧的版本写入到 undo 日志中 这个隐藏列相当于一个指针可以通过它来找到该记录修改前的信息。我们举个例子来理解它假设表 hero 中只包含一条记录
mysql select * from hero;
----------
|id |name |
----------
|1 |刘备 |
----------
指定插入该记录的事务ID为80此时再开启两个事务对这条记录进行修改每次修改都会生成一条 undo log每条日志也都有 trx_id 属性和 roll_pointer 属性。通过 roll_pointer 属性可以将多条 undo log 连接成一条链表如下图所示 这个链表被称为版本链版本链的头节点是当前最新的记录利用这个记录的版本链可以来控制并发事务访问相同记录时的行为这种方式被称为多版本并发控制。
事务在执行第一次查询的时候会生成一致性快照Read View通过它来判断版本链中的哪个版本对当前事务是可见的。Read View 中包含4个比较重要的内容如下
m_ids: 生成 Read View 时当前系统中活跃的读写事务的 id 列表它用来保证即使活跃的这些事务被提交它们的写入也会被当前事务忽略min_trx_id: 当前系统中活跃的读写事务的最小事务 idmax_trx_id: 系统应该分配给下一个事务的事务 idcreator_id: 生成该 Read View 的事务的事务 id
有了 Read View只需要按照下面的步骤去判断记录中的某个版本是否可见
如果被访问版本的 trx_id 属性值与 Read View 中的 creator 中的 creator_trx_id 值相同则意味着当前事务在访问自己修改过的内容该版本能够被当前事务访问如果被访问的版本的 trx_id 属性值小于 Read View 中的 min_trx_id 值表明生成该版本的事务在当前事务生成 Read View 前已经提交这些版本能够被当前事务访问如果被访问的版本的 trx_id 属性大于或等于 Read View 中的 max_trx_id 值表明生成该版本的事务在当前事务生成 Read View 之后才开启那么该版本不能被当前事务访问如果被访问的版本的 trx_id 属性值在 Read View 的 min_trx_id 和 max_trx_id 之间则需要判断 trx_id 是否在 m_ids 列表中。如果在说明创建该 Read View 时生成该版本的事务还是活跃的所以该版本不可见如果不在说明创建该 Read View 时生成该版本的事务已经被提交该版本可以被访问
也就是说想要满足记录对当前读事务可见需要创建该记录的事务在当前读事务开启前已经提交。
3.4 可串行化
可串行化通常被认为是最强的隔离级别能够避免我们上诉所有数据不一致问题。它能保证即使事务可以并行执行但最终的结果也是一样的就好像它们没有任何并发性连续挨个执行一样。也就是说数据库可以防止所有可能的竞争条件。
可串行化的实现技术大多采用如下3种方式之一串行化执行事务两阶段锁定或可串行化快照隔离。
串行化执行事务
使用这种技术实现必须要求每个事务小而快如果其中有一个缓慢的事务那么自然会将其他事务拖慢。除此之外这种方式限于活跃数据集可以放入内存的情况如果需要在事务中访问磁盘中的数据那么系统也会变得非常慢。写入吞吐量必须低到在单个CPU核上处理如若不然事务需要能划分至单个分区且不需要跨分区协调。当然跨分区事务可以实现但是它的执行效率会非常低。所以串行化执行事务的伸缩性较差。
两阶段锁定2PL, two pahse locking
两阶段提交的含义是第一阶段事务执行时获取锁共享锁/排他锁第二阶段在事务执行完成时释放锁。它要求没有写入时多个事务都可以读取同一个对象但是只要有写入就会独占访问读阻塞写写也会阻塞读与快照隔离不同因此两阶段锁定可以避免竞争条件而实现可串行化。 Mysql的InnoDB引擎实现可串行化隔离级别采用的就是2PL机制。 两阶段锁定的性能很差不仅是因为它获取和释放锁的开销而且还包括并发性的降低因为如果两个事务修改同一个对象时第二个事务必须要等待第一个事务执行完为止。除此之外2PL实现的可串行化隔离出现死锁的情况也比较频繁。
可串行化快照隔离SSI, serializable snapshot isolation
可串行化快照隔离是一种乐观的并发控制技术它在快照隔离的基础上添加了一种算法来检测写入之间的串行化冲突并确定要终止哪些事务。 乐观意味着如果存在潜在的危险也不阻止事务而是继续执行事务希望一切都会好起来。当一个事务想要提交时数据库检查是否有什么不好的事情发生即隔离是否被违反如果是的话事务将被中止并且必须重试。在争用不是很高时乐观的并发控制往往比悲观的并发控制性能要好。 事务从数据库中读取一些数据并根据这些数据进行条件判断执行业务逻辑时在快照隔离的条件下往往先前的查询结果不是最新的因为在数据查询之后该数据可能会被修改所以执行的业务逻辑可能会出现异常。因此在事务提交时判断先前读的数据是否发生改变就需要两方面的校验
检查是否存在读之前未提交的写入检查读之后的写入
只有通过这些校验后才能保证事务提交时使用的数据是新的。
可串行化快照隔离与串行执行相比可串行化快照隔离并不局限于单个 CPU 核的吞吐量所以它的伸缩性更好可串行化快照隔离与两阶段锁定相比它的最大优点是一个事务不需要阻塞等待另一个事务所持有的锁就像在快照隔离下一样读不阻塞写写也不阻塞读这对于读取较多的业务场景非常友好。
可串行化快照隔离的性能表现在中止率上如果长时间的读写事务较多很可能会经常发生冲突导致事务中止。因此在事务比较短小的情况下可串行化快照隔离的表现更好。
4. 及时性与完整性
ACID事务通常能保证强一致性也就是说写入者会等到事务提交而且在写入完成后写入结果对所有读取者可见。在强一致性这个语义中包含两个特别值得考虑的方面
及时性这意味着确保用户观察到系统的最新状态。如果不是强一致性而是最终一致性的情况那么用户可能会读取到陈旧的数据但这种不一致是暂时的最终都会通过等待与简单地重试得到解决完整性完整性代表数据没有丢失、矛盾或错误即没有损坏。尤其是某些衍生数据集缓存、搜索索引等它们一定要与底层数据库保持一致。在ACID事务中原子性和持久性是保证完整性的重要原则
有意思的是基于异步流处理系统实现的分布式事务它能够将及时性与完整性分开只保证完整性而不保证及时性除非我们显示地构建一个在事务提交返回结果之前明确等待特定消息到达的消费者。
下面我们来看一个基于流处理系统实现分布式事务的例子来加深对及时性和完整性的理解。
4.1 使用基于日志的消息队列保证完整性
我们以转账为例比如有三个分区一个包含请求ID一个包含收款人账户另一个包含付款人账户。如果在数据库传统的方法中执行此事务需要跨三个分区进行原子提交这样就需要协调分布式事务因此吞吐量很可能会受到影响。但事实上使用基于日志的消息队列实现的流处理系统可以达到等价的数据完整性而不需要原子提交。例子执行过程如下
从账户 A 向账户 B 转账的请求由客户端提供一个唯一的请求 ID并按请求 ID 追加写入相应的消息队列并对该消息进行持久化消费者读取请求日志。对于每个请求消息它向输出流发出两条消息付款人的借记指令A分区收款人的贷记指令B分区发出的消息中会携带原始的请求ID后续消费者消费借记和贷记指令按照ID除重并将变更应用到账户的余额
为了在多分区间保证数据完整性而且还要避免对分布式事务的协调2PC等协议我们首先需要将这个事务所要做的事情持久化为单条记录然后从这条消息记录中衍生出贷记指令和借记指令。在几乎所有的数据系统中单对象的写入都是原子性的即请求要么出现在日志中要么都不出现。
如果流处理在步骤2崩溃则它会从上一个存档点恢复处理这样它就不会跳过任何消息但可能会生成多条重复的借记/贷记指令不过由于它是确定性的因此它生成的只是相同的指令在步骤3中的处理器可以通过ID值轻松地去重。
在上述例子中我们把一个操作拆分为跨越多个阶段的流处理器消息记录的消费是异步的发送者不会等其消息被消费处理完而且这个消息与消息的处理结果被解耦所以我们没有对及时性进行保证只是保证了完整性。
一般地我们在借助可靠的流处理系统时无需再协调分布式事务或采用其他原子提交协议就能保证完整性其中所包含的机制如下
将写入操作的内容表示为单条消息这样就保证了写入的原子性从这一消息中衍生出其他所需要的状态变更将客户端生成的请求ID传递通过所有的处理层从而能达到去重和保证幂等性的目的保证消息不可变并允许衍生数据能被随时重新处理这使从错误中恢复更加容易
4.2 完整性的重要性
不论是ACID事务还是基于流处理系统的分布式事务它们都保证数据的完整性。因为违反及时性可能会令人困惑不过这只是暂时的但是如果违反完整性那么它的结果可能是灾难性的。违反一致性最终一致性违反完整性永无一致性是最好的概括。 巨人的肩膀
《数据密集型应用系统设计》第七章 事务、第十二章 数据系统的未来Replication下事务一致性与共识《MySQL是怎样运行的》第二十一章《高性能MySQL 第四版》第一章 作者京东物流 王奕龙 来源京东云开发者社区
