本地事务设计(2)-读已提交（Read Committed）设计哲学

若两个事务不触及相同数据，即无数据依赖关系，则它们能安全并行运行。只有当：

• 某事务读取另一个事务同时修改的数据
• 或两个事务同时修改相同数据

才会出现并发问题。

并发 BUG 很难通过测试找到，因为这样的错误只有在特殊时序下才会触发。这样的时序问题可能非常少发生，通常很难重现。并发性也很难推理，特别是在大型应用中，你不一定知道哪些其他代码正在访问DB。只有一个用户访问数据时，应用开发就够麻烦了，多用户并发更困难，每个数据都可能被多个用户修改。

因此，DB一直试图通过【事务隔离】来隐藏内部各种并发问题。理论上，隔离是假装无并发发生，让程序员不再996。而可串行化隔离级别就是DB保证事务最终效果如同串行执行。但可串行化有极大性能损失，许多DB不愿意牺牲性能，所以倾向较弱隔离级别，防止某些而非全部并发问题。

弱隔离导致的并发性错误不仅是理论问题，它们已造成很多资损，审计调查和客户数据破坏。比起盲目依赖工具，不如对各种并发问题及如何防止有深入理解，构建可靠、正确的应用。

最基本的事务隔离级别，提供如下保证：

1. 读DB时，只能看到已成功提交的数据（防脏读）
2. 写DB时，只会覆盖已成功写入的数据（防脏写）

1 防止脏读

某事务已完成部分数据写，但事务尚未提交或中止。另一个事务可以看到尚未提交的数据吗？是，则为脏读。

读已提交的事务必须防止脏读，即事务的任何写只有在事务成功提交后才能被其他人看到。如图-4，用户1设置​​x=3​​​，但用户2​​get x​​ 仍旧返回旧值2（用户1还未提交）。

图-4 没有脏读：用户2只有在用户1的事务已提交后才能看到x新值

1.1 防止脏读的意义

• 若事务需更新多个对象，脏读代表另一个事务可能只看到部分更新。如图-2，用户看到新的未读邮件，但看不到更新的计数器。这就是电邮脏读。看到部分更新的数据会让用户困惑
• 若事务中止，则所有写都得回滚（如图-3）。若发生脏读，意味着一个事务可能看到稍后需回滚的数据，即从未实际提交给DB的数据。

2 防止脏写

若两个事务同时尝试更新DB的相同对象，不知道写的顺序如何，但通常认为后写入会覆盖前写入。

但若先前写入是尚未提交事务的一部分，是否还被覆盖？是，则为脏写。RC下的事务可以防止脏写，一般就是延迟后写，直到前写事务完成提交或中止。

防止脏写可避免如下并发问题：

• 若事务需更新多个对象，如图-5的二手车销售网站，Alice 和 Bob 同时购买同一辆车。购买汽车需两次DB写入：网站上的商品列表需更新，以反映买家购买，销售发票需发给买家。图-5的销售属于 Bob（因为他成功更新车辆列表），但发票却寄给了爱丽丝（因为她成功地先更新了发票表）。RC就能避免此类事故。
• 但RC不能防止图-1的计数器增量竞争。它的第二次写入确实发生在第一个事务提交后，所以不是脏写，但结果仍不正确。防止更新丢失中将讨论如何修正

图-5：若存在脏写，来自不同事务的冲突写入可能混杂

3 实现原理

互联网主流隔离级别，Oracle 11g、PostgreSQL、SQL Server 2012、MemSQL和其他许多DB的默认设置。

3.1 防脏写

DB一般通过 行锁（row-level lock）防脏写：当事务想修改某对象（如行或文档），须先获得该对象的锁。然后一直持有，直到事务结束。一次只有一个事务可持有特定对象的锁；若另一事务想更新同一对象，则必须等到前面事务完成，才能获取锁并继续。这是RC模式（或更高隔离级别）DB自动完成的锁定。

3.2 防脏读

① 方案一

使用相同的锁，所有想读该对象的事务必须先申请锁，事务完成后释放锁。确保不会发生读脏的、未提交的值(因为锁在此期间，一直由一个事务持有)。

但要求读锁，实践效果不好。因为耗时长的写事务会迫使许多只读事务等该慢写事务完成。这会严重增大只读事务的响应延迟，且可操作性差：由于读锁，应用的局部性能问题可能由于连锁效应，扩散导致其他部分都受影响。

② 方案二

因此，大多DB [^vi] 使用图-4方案防脏读：对于写入的每个对象，DB都会记住旧的已提交值，和由当前持有写锁的事务设置的新值。当事务进行时，任何其他读取对象的事务都会取旧值。当新值提交后，事务才会切换到读新值。

[^vi]: 唯一在RC使用读锁的主流DB是使用 ​​read_committed_snapshot = off​​ 配置的 IBM DB2 和 Microsoft SQL Server。

文章转载自公众号：  JavaEdge