精通Java事务编程(4)-弱隔离级别之防止更新丢失

x33g5p2x  于2022-07-26 转载在 Java  
字(2.5k)|赞(0)|评价(0)|浏览(226)

RC和快照隔离级别主要都是为解决 只读事务遇到并发写时可以看到什么(虽然中间也涉及脏写),还没触及另一种情况:两个写事务并发,而脏写只是写并发的特例。

写事务并发带来最着名的问题就是丢失更新,如图-1的两个并发计数器增量为例。

应用从DB读一些值,修改它并写回修改后的值,则可能导致丢失更新。若两事务同时执行,则其中一个的修改可能丢失,因为第二个写内容并未包括第一个事务的修改(有时会说后面的写入 狠揍(clobber) 了前面的写入)这种模式发生在各种不同场景:

  • 增加计数器或更新账户余额(需要读取当前值,计算新值并写回更新后的值)
  • 在复杂值中进行本地修改:例如,将元素添加到 JSON 文档中的一个列表(需要解析文档,进行更改并写回修改的文档)
  • 两个用户同时编辑 wiki 页面,每个用户通过将整个页面内容发送到服务器来保存其更改,覆写数据库中当前的任何内容。

这是一个普遍的问题,所以已经开发了各种解决方案。

2.3.1 原子写

许多DB支持原子更新,避免了在应用程序代码中执行读取 - 修改 - 写入。用这些操作通常是最好的解决方案。如下指令在大多数关系DB中并发安全:

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

类似像:

  • MongoDB文档DB提供了对 JSON 文档的一部分进行本地修改的原子操作
  • Redis支持修改数据结构(如优先级队列)的原子操作

并不是所有的写操作都可以用原子操作的方式来表达,例如维基页面的更新涉及到任意文本编辑 1,但是在可以使用原子操作的情况下,它们通常是最好的选择。

实现方案
  • 一般采用对读取对象加排它锁来实现,以便在更新完成之前没有其他事务可以读它。这种技术有时被称为游标稳定性(cursor stability)
  • 另一个实现方案是强制所有的原子操作在单线程执行。

但ORM框架很容易导致执行不安全的读取 - 修改 - 写入,而不是使用数据库提供的原子操作。若你知道自己在做什么,或许这不会引发什么问题,但往往会埋下潜在Bug。

2.3.2 显式加锁

若DB不支持内置原子操作,防止丢失更新的另一个选择是让应用程序显式锁定待更新对象。然后应用程序执行读取 - 修改 - 写入,此时若其他事务尝试同时读取对象,则必须等待,直到第一个 读取 - 修改 - 写入 完成。

如多人游戏,其中几个玩家能同时移动同一个数字。只靠原子操作可能不够,因为应用程序还需确保玩家的移动符合规则,这可能涉及一些应用层逻辑,不可能将其剥离转移给DB层在查询时执行。此时,可使用锁来防止两名玩家同时移动相同棋子,如例-1:

例-1 显式锁定行,以防止丢失更新

BEGIN TRANSACTION;

SELECT * FROM figures
  WHERE name = 'robot' AND game_id = 222
  # 指示DB对返回的所有结果行要加锁。
  FOR UPDATE;

-- 检查玩家的操作是否有效,然后更新先前 SELECT 返回棋子的位置
UPDATE figures SET position = 'c4' WHERE id = 1234;

COMMIT;

这有效,但要做对,需仔细考虑应用层逻辑。忘记在代码某处加锁很容易引入竞争条件。

2.3.3 自动检测更新丢失

原子操作和锁是通过强制 读取 - 修改 - 写入 串行执行来避免丢失更新。

另一种方法是允许它们并发,但若事务管理器检测到丢失更新,则中止当前事务,并强制它们回退到安全的 读取 - 修改 - 写入。

该方案的一个优点是DB能结合快照隔离高效执行检查。PostgreSQL的可重复读,Oracle的可串行化和 SQL Server 的快照隔离级别,都能自动检测到丢失更新,并中止违规的事务。但MySQL/InnoDB的可重复读并不会检测丢失更新。一些作者认为,DB必须防止丢失更新,才称得上是提供了快照隔离,所以在这种定义下,MySQL属于没有安全支持快照级别隔离。

丢失更新检测是个好功能,应用代码因此不依赖某些特殊的DB功能。你可能忘记使用锁或原子操作,但丢失更新的检测会自动生效,就不太容易出错。

2.3.4 CAS

不提供事务的DB有时支持CAS,可避免丢失更新:只有当前值从上次读取时一直未改变,才允许更新发生。若当前值与先前读取的值不匹配,则更新不起作用,就重试读取 - 修改 - 写入。

如为防止两个用户同时更新同一个 wiki,可尝试如下操作,只有当页面从上次读取之后没发生变化时,才会执行当前的更新:

-- 根据数据库的实现情况,这可能安全也可能不安全
UPDATE wiki_pages SET content = 'new content'
  WHERE id = 1234 AND content = 'old content';

若内容已更改且不再与 “旧内容” 匹配,则更新失败,需应用层再次检查更新是否生效,必要时重试。若WHERE语句运行在DB的某个旧快照,即使另一个并发写入正在运行,条件可能仍为真,最终可能无法防止更新丢失。所以在使用前,应先仔细检查“比较-设置”操作的安全运行条件。

2.3.5 冲突解决和复制

支持多副本的数据库中,防止丢失更新还需考虑:由于多节点上存在数据副本,不同节点可能并发修改数据,需采取额外措施防止丢失更新。

加锁、CAS前提都要求只有一个最新的数据副本。但多主或无主复制的多副本DB,通常允许多个并发写,并异步复制到副本,所以会出现多个最新的数据副本。此时加锁或CAS将不再适用。

正如系列文章(5)中的【检测并发写入】一节所述,多副本DB通常允许并发写入创建多个冲突版本的值(互称为兄弟),并使用应用层代码或特殊数据结构来解决、合并这些多版本。

若操作可交换(顺序无关,在不同副本上以不同顺序执行时,仍得到相同结果),则原子操作在多副本情况下也能工作。如递增计数器或向集合添加元素都是典型的可交换操作。这是 Riak 2.0 新数据类型思想,当一个值被不同客户端同时更新时, Riak自动将更新合并在一起,避免发生更新丢失。

而最后写入胜利(LWW)的冲突解决方法则容易丢失更新,不幸的是,LWW目前是许多多副本DB的默认配置。

  1. 将文本文档的编辑表示为原子的变化流是可能的,尽管相当复杂。请参阅 “自动冲突解决”。 ↩︎

相关文章

微信公众号

最新文章

更多