如果两个事务操作的是不同的数据，那它们可以安全地并发执行。只有当两个事务操作相同的数据时，才会有并发的问题，而事务中的隔离性就是保证每个事务能够像串行执行那样，不会由于并发执行对最终结果造成影响。
严格的隔离性在实现起来会有很大的性能代价，许多数据库并不愿意承担这样的代价，因此提出了弱隔离性的概念，下面我们会介绍几种常见的弱隔离性的概念和实现。
Read Committed
最基本的事务隔离性是read committed，它可以做出以下两个保障：
- No dirty reads：读数据库时，只能读到已经提交后的数据；
- No dirty writes：写数据库时，只能覆盖已经提交后的数据。
No dirty reads
我们先来看一下No dirty read的场景：有两个客户端同时修改数据，用户1在事务中修改x和y的值为3，同时用户2在读取x和y的值。在用户1未commit之前，用户2读取到的x和y的值都为原始值2，在用户1commit后，用户2读取到x的值为3。
为什么要防止dirty read的情况呢？dirty read的可能会导致以下两种可能出现的问题：
- 一个事务正在更新大量的数据，另一个事务可能会读取到部分更新，部分未更新的数据，出现错误的结果；
- 一个事务的写操作可能会回滚，如果另一个事务读到了这部分数据，可能会无法解释数据更新的顺序性。
No dirty writes
Dirty Write指的是写操作会覆盖未commit的数据，下面是一个Dirty Write的示例：在一个二手车购买网站上，Alice和Bob同时尝试购买一辆车。购买车的时候需要更新两个数据库，分别是网站的车辆列表，和购车者的账单信息。由于两个事务共同写入一行数据，按照图中的时序关系，最终网站列表中车属于Bob，但账单显示车属于Alice，出现数据错误的情况。
如果写操作不会覆盖未commit的数据，就可以保证不会出现这样的情况。用户2的写操作，只会在用户1的写操作提交后才会执行，最终会完全覆盖用户1的数据。
这里注意，Read Committed的隔离性保证，并不能避免两个自增操作的竞争条件，如下图所示，第二个写操作在写入时，第一个操作已经commit，因此第二个写操作并不是dirty write，但结果确实错误的。后面会介绍避免这种情况的弱隔离性保证。
实现方式
最常见的避免dirty writes的方式是使用数据库的行级锁。当一个事务想修改一个特定的数据行或文档时，必须首先获得它的锁，直到事务commit或者中断会释放锁。另外一个想修改相同数据的事务，会一直等待直到获取到锁。
如何避免dirty reads呢？如果同样也用锁的方式，也是可行的，但由于读和写不能同时进行，如果一个事务长时间写数据，其他事务将无法读数据，一直在等待，性能的损失会很严重。
另一种避免dirty reads的方式，是数据库同时保存旧的已经提交的数据，以及占有锁的事务的新数据。当事务未commit前，读取该数据会获得旧的值，只有当事务commit后，才会读取到新值。
Snapshot Isolation
Read Commit的隔离性可以保证我们读取不到未完成的事务的数据，但仍然会有一些问题存在。如下图所示，Alice先读取到账户1的余额是500，Transfer将Account1的100余额转移给Account2，这时Alice读取到账户2的余额是400，两个账户的余额总和是900，而不是1000。
这种异常情况被称为不可复现的读（nonrepeatable read）或者read skew。这种情况并不会持续的出现，最终Alice一定会读取到账户1的余额是600，账户2的余额是400，余额总和为1000。即使如此，在一些场景下，这种情况仍然会导致问题：
备份：如果有一个请求会备份数据库的所有数据，如果数据库很大，备份的时间很长。在备份过程中，可能会获取到旧版本的数据，也可能获取新版本的数据。如果用这种的数据恢复数据库时，就会导致数据不一致的情况。
分析查询和完整性检查：分析查询和完整性检查一般需要扫描大量的数据，因此也容易查询到无法理解的错误数据。
Snapshot隔离性是一种常见的解决方案，基本思想是每个事务读取数据库相同的快照，只读取事务开始的时间点的数据，即使在这个过程中，有其他事务修改了数据库的数据值。这样对于上述的两个场景，数据在事务开始时就冻结了，因此不会出现无法理解的查询结果。
实现方式
和Read Committed隔离性类似，snapshot隔离性也用写锁来避免dirty writes，但读并不需要任何锁，因此从性能角度来看，snapshot隔离性的原则是：读和写之间不会互相阻塞。
Read Committed保存两个版本的数据，避免dirty reads的情况。Snapshot隔离性会记录每个事务的修改记录，保留数据的多个版本，因此也称为多版本并发控制（MVVC：multiple version concurrency control）。
下图是Snapshot隔离性的示意图，每个事务分配一个唯一的事务ID（txid），当事务写数据库时，它写的数据会带有事务ID作为标签。
表中每一行都带有created_by字段，包括写入该数据的txid；同时包含deleted_by字段，初始值为null，当有事务写数据时，将旧数据行的deleted_by记录为该事务的txid。这样在txid=12的事务在读取数据时，就可以通过created_by和deleted_by的判断，从多行数据记录中读取到txid=13更新前的数据。
可见性规则
通过定义以下的可见性规则，可以通过txid获取到一致的快照数据：
- 在事务开始时，获取到当前未commit的所有事务的列表，这些事务的写入数据将会被忽略；
- 中止事务的写入数据将会被忽略；
- 晚于当前txid的事务的写入将会被忽略，无论这些事务是否已经commit；
- 其他写入都是可见的。
可以结合上述的可见性规则，再重新回顾下上面图中的示例。
把可见性规则换一个角度，什么样的数据是可见的：
- 在事务开始时，已经commit的事务的写入数据是可见的；
- 数据对象未删除，或者在事务开始时，删除的事务还没有commit。
Index的处理
在多版本的数据库中，index是如何工作的呢？一种方式是index指向数据对象的所有版本，然后通过index查询过滤掉当前事务不可见的数据。垃圾收集器会移出任何事务都不可见的旧版本数据，相应的index入口也会被移出。
另一种方式是使用B-trees，这里使用的是append-only/write-on-copy的变量，并不覆盖树的pages，而是为每个修改的的page创建一个副本。树的父节点，直到根节点，都指向新的page，没有修改的page不需要拷贝，保持不变。
使用这种只能追加的B-trees，每个事务将创建出一个新的B-tree的root，每个root是数据库的一个镜像版本，这样在访问B-tree的数据时，就不需要再进行过滤了。该方法同样需要进行后台的压缩和垃圾回收。
其他名字
Snapshot隔离性还有其他名字，比如在Oracle中称作序列化（Serializable），在PostgreSQL和MySQL中称为可重复读（repeatable read）。
小结
本节介绍了弱隔离性的两种方式：Read Committed和Snapshot，他们解决了一部分的并发问题，但仍会有一些场景产生错误的数据。下一节会继续介绍另外两种弱隔离性的方式。
