《设计数据密集型应用》第七章(4) 事务：弱隔离性(2)

前面介绍的两种弱隔离性的级别，Read Committed Isolation和Snapshot Isolation，可以保证正确的处理并发的读请求，但对于并发写的情况，仅保证了不会出现Dirty writes，仍然会出现比如两个事务同时更新一个数据变量，其中一个事务的更新丢失的情况。我们接下来会继续介绍两种弱隔离性，能够在一定程度上避免其他的并发问题。

避免Lost Updates

我们再回顾一下Lost Updates的情况，如下图所示，两个事务同时更新一个数值，最终该值仅增加1，而丢失了一个事务的更新操作。

Lost Updates

Lost Updates的情况同样可能出现在以下的场景：

• 增大计数器，或者更新账户余额：需要先读取当前值，计算新值，并写回更新的值；
• 更新复杂对象，比如在Json文档数据中增加一个key：需要先解析文档，进行修改，然后写回修改后的文档；
• 两个用户同时更新wiki页面，每个用户的修改发送到服务器，覆盖原有的数据。

避免Lost Updates的方式有以下几种：

原子写操作

许多数据库可以提供原子操作，可以不用在应用代码中使用read-modify-write的操作，在应用程序中使用这些原子操作一般是最好的做法，比如以下的SQL语句是并发安全的：

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

同样的，在文档型数据库中，MongoDB提供了对Json文档修改的原子操作，Redis提供了对比如priority queues的数据修改的原子操作。

原子操作并不能满足所有场景的lost updates问题，比如两个用户同时更新wiki页面的问题，就不能通过原子操作实现。

原子操作的实现，一般都是通过在对象上增加排他锁（exclusive lock）实现的，也就是在一个事务读数据时，另一个事务只有在该事务完成更新后才能读，这也被称为cursor stability。另外一种实现方式时，让所有的原子操作都在一个线程顺序执行。

外部锁

如果数据库内置的原子操作不能提供必要的功能，应用程序需要在更新数据时自己添加锁。这样应用程序在执行read-modify-write时，其他事务就只能等待，直到前一个操作完成。

假设有一个多人游戏，每个玩家都可以移动同一目标的位置。单纯进行移动的原子操作是不够的，因此在移动前需要判断移动是否是合理的。这里用外部锁实现的代码如下所示：

BEGIN TRANSACTION;

SELECT * FROM figures
WHERE name = 'robot' AND game_id = 222
FOR UPDATE;

-- Check whether move is valid, then update the position
-- of the piece that was returned by the previous SELECT.

UPDATE figures SET position = 'c4' WHERE id = 1234;

COMMIT;

自动检测lost updates

之前提到的原子写操作和外部锁，都是强制让read-modify-write类型的所有操作是顺序发生的。因此，另一种方式是允许它们并行执行，然后由事务管理器检测lost update，一旦检测到，会中止该事务并重新执行。

这种方法的优点是，对于支持Snapshot Isolation的数据库，可以很有效地进行该检查。我个人的理解是由于Snapshot Isolation会为每个事务分配一个txid，并且记录了每个txid修改的数据版本，可以在最终write时判断数据是否被修改，如果修改则中止事务并重试。PostgreSQL、Oracle和SQL Server都提供了类似的特性，而MySQL/InnoDB并没有提供。

Lost updates的检测是很有用的特性，可以简化应用程序代码的复杂性，并且防止由于忘记使用原子操作和锁导致的错误，使得程序更不易出错。

Compare-and-set

对于一些不提供事务的数据库，使用原子性的Compare-and-set操作，可以保证数据在修改时，当前值等于读取时的值。如果当前值发生变化，更新时什么都不会发生，read-modify-write的操作将会重试。

例如之前提到的两个用户同时更新wiki的例子，用这种方法更新时的SQL语句如下：

-- This may or may not be safe, depending on the database implementation
UPDATE wiki_pages SET content = 'new content'
WHERE id = 1234 AND content = 'old content';

如果content在修改的过程中变化，那么更新将什么都不发生，因此需要检测该更新是否生效，并在必要的情况下重试。然而，如果数据库应用了Snapshot Isolation，可能WHERE条件读取到的是旧的值，而当前值其实已经变化了。因此要仔细确认compare-and-set的操作是否是安全的。

多副本的冲突解决

在多副本的数据库，避免lost updates需要从其他维度来考虑：数据会拷贝到多个节点上，并且不同节点的数据可能会并发修改。

原子操作可以在多副本的情况工作的很好，特别是符合交换律的场景，也就是不同顺序的计算结果是相同的。

锁和compare-and-set的方法，都假设自己是最新的数据副本。然后，对于leaderless和multiple-leader的模型，同时会有多个写操作并发执行，并且进行异步复制，并不能保证哪个节点的数据是最新的。因此锁和compare-and-set在此时就不适用了。

一种常见的解决方式，是允许向数据库中写入有冲突的多个版本的值，并且在应用程序中分析并解决冲突。

之前我们讲到的last write wins（LWW）的并发写入策略，是很容易出现lost updates情况的。