支持串行隔离级别_从0到1理解数据库事务（上）：并发问题与隔离级别

最近准备写一篇关于Spanner事务的分享，所以先分享一些基础知识，涉及ACID、隔离级别、MVCC、锁，由于太长，只好拆分成上下两篇：

上：并发问题与隔离级别

主要讲事务所要解决的问题、思路，先理解为什么需要事务以及事务并发控制中面临的问题。

下：隔离级别实现——MVCC与锁

隔离性是为了更好地做到并发控制，事务的并发表现会对业务有直接影响，所以这篇会详细讲如何实现隔离，主要是讲两种主流技术方案——MVCC与锁，理解了MVCC与锁，就可以举一反三地看各种数据库并发控制方案，并理解每种实现能解决的问题以及需要开发者自己注意的并发问题，以更好支撑业务开发。

文章开始前先给一个小思考，考虑一个情况：
像下面这样实现User提现100元，是否一定不会出问题？
Start Transaction
SELECT balance FROM users WHERE user_name=x; （此次读取在Transaction中）
在代码中判断balance是否大于等于100
如果小于100元，End Transaction并且返回余额不足提现失败
如果大于等于100元，则 UPDATE users SET balance = balance - 100 WHERE user_name=x; 然后Commit Transaction，返回提现成功

如果你已经很理解数据库事务了，一定知道什么情况有问题，以及为什么出现这个问题，这篇文章对你太入门，不用继续看。如果不太清楚，那希望你看完上、下两篇就非常理解了，否则就是我写得太烂。

一、重新理解 ACID

1. 数据操作中面临的问题

技术中的所有方案必定是为了解决特定问题，先理解问题再看方案，学起来更简单、理解更深入，所以先从数据库面临的问题说起。

首先，要理解为什么数据库会有事务的需求，先理解数据库要解决的根本问题不是存储，存储问题已经被文件系统解决了，数据库的目的是如何帮助开发者更可靠、更快速、更便利地使用存储，更好地帮助开发者完成业务，业务中一个高频需求是：有一批连续的操作，这一批操作要么全部成功，要么就可以像没有发生过一样，不要由于部分未成功而导致脏数据产生。如果没有事务，我们处理用户下单的业务场景，就要超级多的代码去handle各种错误、清理各种脏数据、避免可能的bug，比如下单成功却由于数据库宕机导致没有扣款。为了提高开发效率、降低开发成本，就需要数据库能提供一种保证：将一组操作看作一个单元，这一单元可以全部成功，在部分失败的情况下，可以完全回滚，就像没有发生，这一组操作称为事务（Transaction）。

但是仅仅做到上面那一点是不够的，因为这一个简单需求，其实引入了另一个问题，请注意重点——“一组操作”，事务中可能存在着多个独立操作，他们组合为一组操作，理解多线程编程的同学一定会马上想到，这就会出现经典的并发问题，多个事务间如果不进行并发控制，就会产生各种意外结果，这不是使用者想要的。

总结一下，数据操作中面临的问题：
如何将一组操作看作一个整体，要么全部成功，要么全部回滚。
如何在满足上一条需求的情况下，能够对它进行并发控制，保证不要出现意外结果。

2. 我们需要什么：ACID

ACID 是为了解决上述问题所总结出，为保证事务是正确可靠的，所必须具备的四个特性：

1. 原子性（Atomicity）

事务中的原子性是一个常常被大家误解的特性，因为这个原子性的意思和我们通常语境下的原子性不太一样，大多数时候原子性是指一条不可再分割、不会被中断影响的指令，比如读取一个内存地址的值、将值写回内存地址、redis的SETNX（set if not exists），这些操作都符合我们常说的原子性。

可是事务中的原子性，并不是指事务具有不被中断影响的特点，它仅仅是指，事务中的所有操作应该被看作不可分割的一组指令，任何一个指令不能独立存在，要么全部成功执行，要么全部不发生（也就是回滚）。

还有很多同学对这里所说的“成功执行”有误解，成功执行是指数据库层面的，而不是业务层面的，举个例子，客户购买商品A，可是在购买时，商家刚好下架了商品，那么此时执行 update products where product_id=A and status=销售中 ，由于product的status已经变成“下架”，导致被更新的行数为0，这个算成功执行吗？算！数据库不报错、不宕机、正常运行就是成功，更新行数为0是数据库的正常返回结果，这在业务上是失败，在数据库层面是成功，这种情况数据库不会执行回滚，需要程序员判断更新行数，如果为0，手动回滚。

如果数据库由于硬件或者系统问题发生宕机、报错，这样才算是指令执行失败，此时数据库会重试或者直接回滚，然后将错误返回给开发者。

原子性不止为开发者保证了事务的可靠性（不会因为数据库出错而产生脏数据），还能让开发者手动回滚，提供了业务的便利性。

2. 一致性（Consistency）

这个名词也是相当令人困惑，与数据库主从复制中所说的“一致性”不同，主从复制的一致性是指多个副本间是否完成同步、数据相同，而这里的一致性是指事务是否产生非预期中间状态或结果。比如脏读和不可重复读，产生了非预期中间状态，脏写与丢失修改则产生了非预期结果。一致性实际上是由后面的隔离性去进一步保证的，隔离性达到要求，则可以满足一致性。也就是说，隔离不足会导致事务不满足一致性要求，所以务必理解各个隔离级别，才能少写Bug。

3. 隔离性（Isolation）

简单来说，隔离性就是多个事务互不影响，感觉不到对方存在，这个特性就是为了做并发控制。在多线程编程中，如果大家都读写同一块数据，那么久可能出现最终数据不一致，也就是每条线程都可能被别的线程影响了。按理说，最严格的隔离性实现就是完全感知不到其他并发事务的存在，多个并发事务无论如何调度，结果都与串行执行一样。为了达到串行效果，目前采用的方式一般是两阶段加锁（Two Phase Locking），但是读写都加锁效率非常低，读写之间只能排队执行，有时候为了效率，原则是可以妥协的，于是隔离性并不严格，它被分为了多种级别，从高到低分别为：

⬇️可串行化（Serializable）
⬇️可重复读（Read Repeatable）
⬇️已提交读（Read Committed）
⬇️未提交读（Read Uncommitted）

每一个级别都只是指导标准，每个数据库对其的实现都有差异，有的数据库在Read Committed级别时，就已经实现了Read Repeatable的效果，有的数据库干脆不提供Read Uncommitted级别。

在隔离级别为Serializable时，就会感觉到事务像一个完完全全的原子操作，不被任何中断、并发所影响。

很多开发者理解的事务可能就在Serializable级别，大家误以为事务都是可串行化的，其实并不是，大多数的数据库默认隔离级别都不是可串行化，大多数在Read Repeatable或者Read Committed，要是按照可串行化的思维去编程，却用着低于可串行化的隔离级别，就很容易写出导致数据在业务层面不一致的代码，所以开发者一定要理解各个隔离级别及其原理，更好地支撑业务开发，下面会仔细地讲隔离级别及其实现。

4. 持久性（Duration）

这是ACID中最好理解的，即事务成功提交后，对数据的修改永久的，即使系统发生故障，也不会丢失，这里所说的故障，也只是一般错误比如宕机、系统Bug、断电，如果是硬盘损毁，那就没办法，数据一定会丢失。

二、并发问题与隔离级别

在讨论各个隔离级别的实现之前，先看一下在事务并发执行时，隔离不足会导致的问题。

脏写（Dirty Write）

还未提交的事务写了另一个未提交事务所写过的数据，称为脏写，比如：

两个并发执行的事务A、B，A写了x，在A还未提交前，B也写了x，然后A提交，此时虽然B还没有提交，但是A也会发现自己写的x不见了。

很多地方用“覆盖”去形容脏写，但是我觉得不太适合，因为覆盖暗示了一种先后链条，某个事务写了数据，在昨天就提交了，今天有事务来写同一个数据，可以称之为覆盖，昨天的数据成为历史，但这不是脏写，所以更适合的形容可能是“擦除”，事务发现自己的提交被别人擦除，好像不存在。

脏写是事务一定不允许发生的，所以不管是哪个隔离级别都一定不允许脏写。

脏读（Dirty Read）

由于事务的可回滚特性，因此commit前的任何读写，都有被撤销的可能，假如某个事物读取了还未commit事务的写数据，后来对方回滚了，那么读到的就是脏数据，因为它已经不存在了。

避免脏读可以采用加锁或者快照读的解决方案。在已提交读（Read Committed）级别就可以避免脏读，因为读到的一定是已经Commit的数据。在业务开发中，虽然有未提交读（Read Uncommitted），但是几乎是没有人会用的，读到脏数据一般对业务是很大的伤害，所以有的数据库干脆都不支持未提交读，比如PostgreSQL。

不可重复读（Non-Repeatable Read）

事务A读取一个值，但是没有对它进行任何修改，另一个并发事务B修改了这个值并且提交了，事务A再去读，发现已经不是自己第一次读到的值了，是B修改后的值，就是不可重复读。

简单来说就是第一次读的值，啥都没做，下次读它也有可能发生变化。

一般数据库使用MVCC，在事务的第一条语句开始时生成Read View，事务之后的所有读取，都是基于同一个Read View，以此避免不可重复读问题。

幻读（Phantom）

与不可重复读非常类似，事务A查询一个范围的值，另一个并发事务B往这个范围中插入了数据并提交，然后事务A再查询相同范围，发现多了一条记录，或者某条记录被别的事务删除，事务A发现少了一条记录。

幻读容易与不可重复读混淆，区别它们只需要记住不可重复读面向的是“同一条记录”，而幻读面向的是“同一个范围”。

MVCC虽然使用快照的方式解决了不可重复读，但是还是不能避免幻读，幻读需要通过范围锁解决，可能大家会觉得很奇怪，为什么快照读无法避免幻读，这个会在下一篇文章中详细讲。

SQL标准中有对于各个隔离级别所允许出现的问题作出规定：

除了以上4个问题外，下面还有3个问题，更偏向业务层面，不过也是由于隔离不足引起的：

读偏斜（Read Skew）

Skew可以理解为不一致，因此读偏斜可以理解为读结果违反业务一致性，比如X、Y两个账户余额都为50，他们总和为100，事务A读X余额为50，然后事务B从X转账50到Y然后提交，事务A在B提交后读Y发现余额为100，那么它们总和变成了150，此时违反业务一致性。

写偏斜（Write Skew）

写偏斜可以理解为事务commit之前写前提被破坏，导致写入了违反业务一致性的数据，网上有个很好的简称为写前提困境，也就是读出某些数据，作为另一些写入的前提条件，但是在提交前，读入的数据就已被别的事务修改并提交，这个事务并不知道，然后commit了自己的另一些写入，写前提在commit前就被修改，导致写入结果违反业务一致性。

写偏斜发生在写前提与写入目标不相同的情境下。

这是业务开发中最容易出错地方，如果开发者不太理解隔离级别，也不知道目前使用的是哪个隔离级别，很可能写出有写偏斜的代码，造成业务不一致。

举个例子：

信用卡系统对不同等级的会员有积分加成，3级会员则每次都3倍积分，同时，会有定时任务检查当积分不满足要求时，就会降级。

首先，会员进行了刷卡消费，此时要计算积分，开启了事务A，读到会员等级为3，与此同时定时任务也开始了，读到会员积分为2800，已经不满足3000分应该降级为2级，然后将会员等级降级为2并且commit，由于事务A读到的等级为3，它还是按照3倍积分为会员增加了积分，会员赚了，多亏那个程序员不理解他使用的事务隔离级别，出现了业务不一致。