数据库里关于事务的并发问题，也叫做竞态条件（race condition）。它是描述并发事务中，一个事务需要读取另一个事务写过的数据。
为了保证事务的串行化，事务必须实现某种程度的隔离机制（ACID中的I）。鉴于串行化对于性能的开销，一般实现弱于串行化的隔离级别。
读提交（read committed）
事务隔离最基础的级别是读提交：
- 只能从数据库中读到提交过的数据（无脏读）;
- 只能更新已经完成写提交的数据（无脏写）;
- 无脏读
脏读是指读取到没有完成（这里指完成提交或者完成回滚）的事务的中间状态数据。读提交保证不会有脏读发生，这意味着事务修改的数据只有在完成之后才能被外部所见。
- 无脏写
并发事务写同一条数据的时候，如果稍早的写操作所在事务还未完成，后续写操作将其覆盖的话，叫做脏写。一般阻塞稍后的写操作，在稍早操作完成提交之后再执行它。
通常情况下，数据系统采用行锁来实现读提交隔离。配合两段锁可以有效避免脏写。在解决脏读上，一般采用返回旧版本数据来解决的。
重复读（Snapshot Isolation and Repeatable Read）
下图说明了一个在读提交场景下的并发问题：
一个非常经典的账户转账问题。上面问题叫做读偏斜（read skew）或者可重复读（repeatable read）。
快照隔离（snapshot isolation）能够解决上面的问题。它是指事务读取的数据都是事务开始前的一致性快照的数据，在事务开始之后所有的数据修改都不能被事务读到。他主要解决了长的只读事务，比如数据备份和数据分析。
类似读提交的思想，在避免脏读上，快照隔离也采用了读锁。而读取操作只能读取旧版本数据。（关于旧版本数据的管理策略，可以搜索MVCC相关的内容，简单来说就是通过created_by和deleted_by两个隐藏字段递增版本号来协助实现的）
避免数据丢失
上面主要谈到的都是在并发只读事务中的数据隔离保证（除了提到了脏写）。其实，在很多场景下会出现并发写事务的数据问题。
并发写事务中，经常会出现的一种情况是更新丢失（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）来自定义约束；
