前言

读书真是一件十分神奇的事件，本篇文章的大部分内容起源《数据密集型利用零碎设计》的第七章事务，过后看的时候很是含糊，尤其是弱隔离级别一块，感觉本人仿佛都能看得懂，但就是不明确作者在表白什么，像是没有一根清晰的主线串起来，找不到宗旨。
但过了一段时间学习其余的常识的时候，有种忽然买通了任督二脉的感觉，特地冲动，故写下本文以做总结。

实质

从实质上来说，事务的隔离级别是为并发管制服务的。在应用程序的开发中咱们常常用锁进行并发管制，确保临界区的资源不会呈现被多个线程同时读写的状况，这其实对应的就是数据库的可串行化级别。
那为什么应用层能够提供可串行化的隔离级别而数据库不能提供呢？
在我的了解中，这是因为应用层对临界资源的拜访都是内存操作，而数据库要保障持久性它须要把临界区的数据flush到磁盘中，这个IO操作是要比内存操作慢好几个数量级的，这导致临界区持有锁的工夫变得不可承受、锁抵触的频率变大，数据库的性能会大大降低。

隔离级别

第一个误区：可反复读级别不担保解决失落更新问题

维基百科上的数据库隔离级别)我认为是有误的！

这里的问题在于事实上Repeatable Read可反复读级别并不担保不呈现失落更新问题，它只担保解决不可反复读问题。

反例证实如下(MySQL RR级别)：

事务A、B同时进行卖出item A的过程，事务A售出4件，事务B售出1件，实践上库存记录应该为原始的10减去4减去1失去5才对，但最初库存的记录显示为9。这是典型的失落更新问题，即2个事务同时开启read-modify-write操作序列，呈现了一个事务笼罩了另外一个事务的写入，但这个过程中没有利用/蕴含/读取/获取到对方更新后的最新值(这表明事务A曾经commit过了，有别于脏写)，换句话说也就是事务B没有利用到事务A的更新后果，好像事务A的更新被失落了一样。

下图是数据库隔离级别和可能呈现的问题表格，“?”表明这个级别是否产生对应问题取决于数据库的具体实现

下图是MySQL的隔离级别，咱们在后面的例子中曾经解释过了MySQL RR不解决失落更新问题，咱们随后会解释为什么它也没有解决幻读问题。

异常情况

原子比拟和设置

在上次读取到的数据没有发生变化时才容许更新，如果发生变化了则回退到平安的read-modify-write形式。例如：update table set value＝newvalue where id＝＊ and value＝oldvalue。
然而该形式有一个问题，如果where条件的判断是基于某一个旧快照来执行的，那么where的判断是没有意义的。所以如果要采纳原子比拟和设置来防止更新失落，那么肯定要确认数据库比拟－设置操作的平安运行条件。

补充阐明

举例

假如有一个文章计数器变量x，事务A、B同时拜访它并筹备给文章访问量进行加1操作；当x=20时，如果呈现事务A读取到了x=20并筹备执行+1操作的这个两头过程(也就是说还没有+1并commit的过程)中，事务B曾经实现了对x的批改并且把x=21的后果提交了。这个时候咱们说事务A的x=20须要作废的，否则B的更新就如同被失落了，但实际上A还是会执行他本人的x=x+1=20+1=21并且提交x=21更新；
失落更新在写锁机制下(只在写操作上上锁，而不是整个read-modify-write过程)以及MySQL的RR级别下都没方法解决这个问题！

脏写&失落更新比照

失落更新强调read-modify-write过程，这往往是个有状态的过程
脏写笼罩的是其余事务未提交的更新，失落更新笼罩了其余事务已提交的更新，导致其余事务的更新看起来像是失落了一样

图例：

幻读

形容

事务A先查问了某些符合条件的语句，事务B随后执行了写入扭转了事务A在雷同条件下的查问后果(通常体现为A select进去的数据行数多/少了）

解决

MySQL RR级别下通过MVCC快照读能够防止查问时的幻读

写歪斜

形容

事务A依据条件查询数据库，并依据所查问初的后果做出相应的某些动作，而后批改数据库。但当事务A提交的时候，反对它做出相应批改的条件曾经不成立了(之前Select出的后果不统一)；
写歪斜是幻读的一种状况；写歪斜也能够了解为狭义的更新失落问题，如果事务A、B读取同一组对象，而后更新其中的一部分；

不同事务更新不同的对象-->可能产生写歪斜
不同事务更新同一个对象-->可能产生脏写/更新失落

解决方案

显式加锁
可串行化隔离级别

第二个误区：MySQL RR级别到底有没有解决幻读问题？

在这里我认为问题的关键在于幻读这个概念是否限定于只读事务的语境下，或者说写歪斜属不属于幻读的领域内:
如果你认为写歪斜属于幻读的领域内，那么仅依附MySQL RR级别下仅依附MVCC(实现原理和乐观锁有类似之处)的模式是无奈防止幻读问题的，须要额定显示地加上next-key lock(乐观锁)去防止；
如果你认为写歪斜不属于幻读的领域内，那么RR级别曾经解决了幻读(限定在只读事务语境下)问题，RR级别下保障了同一事务前后的快照读后果都是统一的。
总得而言，RR级别解决了快照读的幻读问题，但无奈防止以后读的幻读问题，这种状况下须要next-key lock配合解决。但因为这是须要使用者显式加锁同HashMap通过Synchronize润饰各办法实现线程平安)，我认为仅依附RR级别并没有解决幻读问题

在下面这个例子中，咱们能够看到在事务B新增了一行数据当前，事务A还是只能读取到5行数据而没有事务B插入的"Frank"的材料，并没有产生幻读问题；
但假如当初事务A须要为分数最高的前三名玩家减少1个credit，按照上图能够看到前三名的玩家别离是Alice、Carol和Bob，其中Bob的分数最低为740，所以你能够通过UPDATE gamer SET credit=credit+1 WHERE score>=740的原子语句进行更新，在这种状况下事务A的更新是否只影响他目前所能看到的5个玩家的材料呢？试验后果如下图:

能够看到事务A执行更新语句后再次select查问能够看到Frank也查问进去了，产生幻读问题。不仅如此，咱们本来预期事务A只为前三名的玩家减少credit，而当初咱们为4个玩家减少了credit，比原定的3个还多，这种状况属于写歪斜。

进一步解释

实际上RR级别下 MVCC快照读的概念大略能够了解为，当一个事务开启时对数据库的状态做一个snapshot，而后事务内只能看到这个snapshot的内容以及本人所做的更改，而无奈读取到其余事务对数据库所做的更新，这决定了不会呈现不可反复读的景象；
但在MySQL InnoDB实际中能够发现这个规定只限定于SELECT(DQL)指令，而INSERT、UPDATE、DELETE等DML指令看到的不是以后事务创立时的snapshot，而是具体指令执行时数据库被commit过的最新状态。
所以在下面的例子中事务A在执行第一次SELECT的时候看到的是snapshot(快照读防止幻读景象)，而当它执行UPDATE的时候就看到了数据库最新的状态，获取到了玩家Frank并为他减少credit(MySQL RR级别的以后读无奈解决幻读问题）

同样是基于快照隔离实现的RR隔离级别的PostgreSQL，因为它的snapshot不仅作用于DQL指令，也作用于DML指令，所以幻读问题在PostgreSQL的RR级别不会产生；

解决办法

基于后面给出的写歪斜解决方案，咱们在这里能够显式的加锁，例如用MySQL的 Share Lock或是Exclusive Lock指令或者先进行一次SELECT FOR UPDATE，阻塞其它想更改材料的事务即可防止幻读。

例如将事务A批改为即可解决问题(select for update显式上锁，在事务A commit/rollback之前事务B会始终阻塞，解决幻读)

beginSELECT * FROM gamer FOR UPDATE;UPDATE gamer SET credit=credit+1 WHERE score>=740;SELECT * FROM gamer;commit;

Reference

[1] Isolation(database systems)-wikipedia)
[2] 對於 MySQL Repeatable Read Isolation 常見的三個誤解
[3] 《数据密集型利用零碎设计》第七章

集体能力无限本文内容如有谬误欢送批评指正！
欢送拜访我的集体博客！

前言

实质

隔离级别

第一个误区：可反复读级别不担保解决失落更新问题

异常情况

脏写

形容

解决

脏读

形容

解决

读歪斜/不可反复读

形容

解决

失落更新

形容

解决

原子写操作

显式加锁

自动检测更新失落