前言
读书真是一件十分神奇的事件，本篇文章的大部分内容起源《数据密集型利用零碎设计》的第七章事务，过后看的时候很是含糊，尤其是弱隔离级别一块，感觉本人仿佛都能看得懂，但就是不明确作者在表白什么，像是没有一根清晰的主线串起来，找不到宗旨。
但过了一段时间学习其余的常识的时候，有种忽然买通了任督二脉的感觉，特地冲动，故写下本文以做总结。
实质
从实质上来说，事务的隔离级别是为 并发管制 服务的。在应用程序的开发中咱们常常用锁进行并发管制，确保临界区的资源不会呈现被多个线程同时读写的状况，这其实对应的就是数据库的 可串行化级别 。
那为什么应用层能够提供可串行化的隔离级别而数据库不能提供呢？
在我的了解中，这是因为应用层对临界资源的拜访都是内存操作，而数据库要保障持久性它须要把临界区的数据 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 不解决失落更新问题，咱们随后会解释为什么它也没有解决幻读问题。
异常情况
脏写
形容
事务 A 笼罩了其余事务未提交的写入
解决
通过行级锁即可解决，在任何隔离级别下都不会产生
脏读
形容
事务 A 读取了其余事务未提交的写入
解决
提供读已提交隔离级别以上的数据库都能够避免，MySQL 中是通过 RC 级别下的 MVCC 解决的
读歪斜 / 不可反复读
形容
事务 A 在执行过程中，对同一个数据行在不同的工夫点前后读取的后果不统一
解决
提供读可反复读隔离级别以上的数据库都能够避免，MySQL 中是通过 RR 级别下的 MVCC 解决的
失落更新
形容
两个事务同时执行 read-modify-write 的过程，呈现了事务 A 笼罩了事务 B 的写入，但并没有蕴含事务 B 批改后的最新值(已 commit)，导致事务 B 的更新如同失落了一样的后果。
解决
原子写操作
如果数据库提供了原子写操作，那就应用它以实现 read-modify-write 操作，这是举荐的最佳计划。例如在少数关系型数据库中 UPDATE counters SET value=value+1 WHERE key='test' 语句是平安的
显式加锁
如果数据库不反对内置原子操作，能够通过对查问后果显式加锁来解决。对于 mysql 来说，就是 select for update，通过 for update 通知数据库，查问进去的数据行稍后是须要更新的，须要加锁避免其余的事务也来读取更新导致更新失落。
自动检测更新失落
数据库先让事务都并发执行，如果事务管理器检测到有更新失落的危险，间接停止以后事务，而后强制回退到平安的 read-modify-write 形式。
原子比拟和设置
在上次读取到的数据没有发生变化时才容许更新，如果发生变化了则回退到平安的 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 会始终阻塞，解决幻读)
begin
SELECT * 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]《数据密集型利用零碎设计》第七章
集体能力无限 本文内容如有谬误欢送批评指正！
欢送拜访我的集体博客！