数据库事务--事务隔离级别

数据库里关于事务的并发问题，也叫做竞态条件（race condition）。它是描述并发事务中，一个事务需要读取另一个事务写过的数据。
为了保证事务的串行化，事务必须实现某种程度的隔离机制（ACID中的I）。鉴于串行化对于性能的开销，一般实现弱于串行化的隔离级别。

读提交（read committed）

事务隔离最基础的级别是读提交：

1. 只能从数据库中读到提交过的数据（无脏读）;
2. 只能更新已经完成写提交的数据（无脏写）;

• 无脏读

脏读是指读取到没有完成（这里指完成提交或者完成回滚）的事务的中间状态数据。读提交保证不会有脏读发生，这意味着事务修改的数据只有在完成之后才能被外部所见。

无脏读

• 无脏写

并发事务写同一条数据的时候，如果稍早的写操作所在事务还未完成，后续写操作将其覆盖的话，叫做脏写。一般阻塞稍后的写操作，在稍早操作完成提交之后再执行它。

脏写

通常情况下，数据系统采用行锁来实现读提交隔离。配合两段锁可以有效避免脏写。在解决脏读上，一般采用返回旧版本数据来解决的。

重复读（Snapshot Isolation and Repeatable Read）

下图说明了一个在读提交场景下的并发问题：

读提交下的一个并发问题

一个非常经典的账户转账问题。上面问题叫做读偏斜（read skew）或者可重复读（repeatable read）。
快照隔离（snapshot isolation）能够解决上面的问题。它是指事务读取的数据都是事务开始前的一致性快照的数据，在事务开始之后所有的数据修改都不能被事务读到。他主要解决了长的只读事务，比如数据备份和数据分析。
类似读提交的思想，在避免脏读上，快照隔离也采用了读锁。而读取操作只能读取旧版本数据。（关于旧版本数据的管理策略，可以搜索MVCC相关的内容，简单来说就是通过created_by和deleted_by两个隐藏字段递增版本号来协助实现的）

快照隔离下的MVCC

避免数据丢失

上面主要谈到的都是在并发只读事务中的数据隔离保证（除了提到了脏写）。其实，在很多场景下会出现并发写事务的数据问题。
并发写事务中，经常会出现的一种情况是更新丢失（lost update）。在应用进行读-修改-写回（read-modify-write）操作的时候，如果没有恰当的隔离机制，当并发修改的时候，可能会丢失部分的修改数据。比如下面的场景：

• 增加一个计数器或者更新账户余额（读并发进行时，两个事务都是基于原始值进行修改，后提交的事务会覆盖掉先提交事务的结果）
• 在线文档编辑（比如google docs，notion等等）

为了避免这种情况，有下面几种对策：

• 原子写操作
  将读-修改-写回的系列操作合并成一个原子写入操作（比如redis里的increment）或者下面sql语句：

UPDATE counters SET value = value + 1 WHERE key = 'foo';

• 显式加锁
  显式对数据加锁，就可以安全的执行读-修改-写回操作了。一般可以在应用逻辑中显式为读-修改-写回的系列操作加锁。
• 自动探测更新丢失
  串行执行带来并发的损失，一般可以假设不会发生问题，当探测到更新丢失的时候，重试丢失的事务。
• 对比-设置（compare-and-set）
  经典的一个例子是redis中的getset方法，这个命令用于设置指定 key 的值，并返回 key 的旧值。用sql表示就是有条件分支语句的更新语句：

UPDATE wiki_pages SET content = 'new content'
  WHERE id = 1234 AND content = 'old content';

冲突解决与数据备份
在多主架构或者无主架构中，经常会出现并发修改同一个数据对象的情况。一种解决方式是保留所有冲突的数据，交由应用逻辑代码处理冲突。原子修改操作替代读-修改-写回操作，可以避免一些写入冲突。

Write Skew and Phantoms

值班系统图示

上图情况叫做写倾斜（write skew）。不同于脏写，写倾斜写入的是不同的数据对象。

• 原子操作无法避免这种情况，因为涉及到多个数据对象的写入；
• 可以借助db的内置约束（外键、唯一键等等），或者使用数据库触发器（trigger）或物化视图（materialized views）来自定义约束；