数据库相关知识
1.数据库事务ACID特性
数据库事务正确执行的四个基础要素是原子性(Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。
- 原子性：是指事务包含的所有操作要么全部成功，要么全部失败回滚，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚到事务开始前的状态，就像这个事务从来没有被执行过一样。
- 一致性：是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。
拿转账来说，假设用户A和用户B两者的钱加起来一共是5000，那么不管A和B之间如何转账，转几次账，事务结束后两个用户的钱相加起来应该还得是5000，这就是事务的一致性。
-
隔离性：两个事务之间的隔离程度
-
持久性
持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。
2 丢失更新
在互联网中存在着抢购、秒杀等高并发环境，使得数据库在一个多事务的环境中运行，多个事务的并发会产生一系列的问题，主要的问题之一就是丢失更新，一般而言存在两类丢失更新。
假设一个场景，一个账户存在互联网消费和刷卡消费两种形式，而一对夫妻共用这个账户。老公喜欢刷卡消费，老婆喜欢互联网消费，那么可能产生如下表所示场景
表1 第一类丢失更新
|
时间 |
事务一（老公） |
事务二（老婆） |
|
T1 |
查询账户余额为10000元 |
|
|
T2 |
|
查询账户余额为10000元 |
|
T3 |
|
网购1000元 |
|
T4 |
请客吃饭消费1000元 |
|
|
T5 |
提交事务成功，余额9000元 |
|
|
T6 |
|
取消购买，回滚事务到T2时刻，余额10000元 |
整个过程只有老公消费1000元，而在最后的T6时刻，老婆回滚事务，却恢复了原来的初始值10000元，这显然不符合事实。这样的两个事务并发，一个回滚、一个提交成功导致不一致，称之为第一类丢失更新。大部分数据库（包括Mysql和Oracle）基本都已经消灭了这类丢失更新。
第二类丢失更新是我们真正需要关注的内容，还是上面的例子，如表2所示
表2 第二类丢失更新
|
时间 |
事务一（老公） |
事务二（老婆） |
|
T1 |
查询账户余额为10000元 |
|
|
T2 |
|
查询账户余额为10000元 |
|
T3 |
|
网购1000元 |
|
T4 |
请客吃饭消费1000元 |
|
|
T5 |
提交事务成功，余额9000元 |
|
|
T6 |
|
提交事务，根据之前余额10000元，扣减1000元后，余额为9000元 |
整个过程存在两笔交易，一笔是老公的请客吃饭，一笔是老婆的网购，两者都提交了事务，由于在不同的事务中，无法探知其它事务的操作，导致两者提交后，余额都为9000元，而实际正确的应为8000元，这就是第二类丢失更新。为了克服事务之间协助的一致性，数据库标准规范中定义了事务之间的隔离级别，来在不同程度上减少出现丢失更新的可能性---->数据库隔离级别。
隔离级别
隔离级别可以在不同程度上减少丢失更新，按照SQL的标准规范，把隔离级别定义为4层，分别是：脏读（dirty read）、读/写提交（read commit）、可重复读（repeatable read）和序列化（serializable）。
脏读是最低的隔离级别，允许一个事务去读取另一个事务中未提交的数据。
表3 脏读
|
时间 |
事务一（老公） |
事务二（老婆） |
备注 |
|
T1 |
查询余额10000元 |
|
|
|
T2 |
|
查询余额10000元 |
|
|
T3 |
|
网购1000元，余额9000元 |
|
|
T4 |
请客吃饭消费1000元，余额8000元 |
|
读取到事务二，未提交余额为9000元，所以余额为8000元 |
|
T5 |
提交事务 |
|
余额为8000元 |
|
T6 |
|
回滚事务 |
由于第一类丢失更新已经克服，所以余额为错误的8000元 |
由于在T3时刻老婆启动了消费，导致余额为9000元，老公在T4时刻消费，因为用了脏读，所以能够读取老婆消费的余额（事务二未提交的）为9000元，这样余额就为8000元了，于是T5时刻老公提价事务，余额变为了8000元，老婆在T6时刻回滚事务，由于第一类丢失更新已经克服，所以余额为错误的8000元，显然这是一个错误的余额，产生这个错误的根源来自于T4时刻，也就是事务一读取到事务二未提交的事务，这样的场景称之为脏读。
为了克服脏读，SQL标准提出了第二个隔离级别----读/写提交。所谓读写提交，就是说一个事务只能读取另一个事务已经提交的数据。
表4 读/写提交
|
时间 |
事务一（老公） |
事务二（老婆） |
备注 |
|
T1 |
查询余额10000元 |
|
|
|
T2 |
|
查询余额10000元 |
|
|
T3 |
|
网购1000元，余额9000元 |
|
|
T4 |
请客吃饭消费1000元，余额9000元 |
|
由于事务二的余额未提交，采取读/写提交时不能读出，所以余额为9000元 |
|
T5 |
提交事务 |
|
余额为9000元 |
|
T6 |
|
回滚事务 |
由于第一类丢失更新已经克服，所以余额依旧为正确的9000元 |
在T3时刻由于事务采取读/写提交的隔离级别，所以老公无法读取老婆未提交的9000元余额，他只能读取到10000元，所以在消费后余额依旧为9000元。T5时刻提交事务，而T6时刻老婆回滚事务，所以结果为正确的9000元，这样就消除了脏读带来的问题，但是也会引发其它问题，如下表所示。
表5 不可重复读
|
时间 |
事务一（老公） |
事务二（老婆） |
备注 |
|
T1 |
查询余额10000元 |
|
|
|
T2 |
|
查询余额10000元 |
|
|
T3 |
|
网购1000元，余额9000元 |
|
|
T4 |
请客吃饭消费2000元，余额8000元 |
|
由于采取读/写提交，不能读取事务二中未提交的余额9000元 |
|
T5 |
|
继续购物8000元，余额1000元 |
由于采取读/写提交，不能读取事务一中未提交的余额8000元 |
|
T6 |
|
提交事务，余额1000元 |
老婆提交事务，余额更新为1000元 |
|
T7 |
提交事务发现余额为1000元，不足以买单 |
由于采取读/写提交，因此此时事务一可以知道余额不足 |
由于T7时刻事务一知道事务二提交的结果----余额为1000元，导致老公无钱买单的尴尬。对于老公而言，他并不知道老婆做了什么事情，但是账户余额却莫名其妙地从10000元变为了1000元，对他来说，账户余额是不能重复读取的，而是一个会变化的值，这样的场景称之为不可重复读（unrepeatable read），这是读/写提交存在的问题。
为了克服不可重复读带来的错误，SQL标准又提出了一个可重复读的隔离级别来解决问题。注意，可重复读针对的是数据库同一条记录而言的，换句话说，可重复读会使得同一条记录的读/写按照一个序列化进行操作，不会产生交叉情况，这样就能保证同一条数据的一致性，进而保证上述场景的正确性。但是由于数据库并不是只能针对一条数据进行读/写操作，在很多场景，数据库需要同时对多条记录进行读/写，这个时候会产生下面的情况。如下表所示
表6 幻读
|
时间 |
事务一（老公） |
事务二（老婆） |
备注 |
|
T1 |
|
查询消费记录为10条，准备打印 |
初始状态 |
|
T2 |
启用消费一笔 |
|
|
|
T3 |
提价事务 |
|
|
|
T4 |
|
打印消费记录得到11条 |
老婆发现打印了11条消费记录，比查询的10条多了一条。她会认为这条是多余不存在的，这样的场景称之为幻读。 |
老婆在T1查询得到10条记录，到T4打印记录时，并不知道老公在T2和T3时刻进行了消费，导致多一条（可重复读针对的是同一条记录，而这里不是同一条记录）消费记录的产生，她会质疑这条多出来的记录是不是幻读出来的，这样的场景称之为幻读。
为了克服幻读，SQL标准又提出了序列化的隔离级别。它是一种让SQL按照顺序读/写的方式，能够消除数据库事务之间并发产生数据不一致的问题。
表7 各类隔离级别和产生的现象
|
隔离级别 |
脏读 |
不可重复读 |
幻读 |
|
脏读 |
√ |
√ |
√ |
|
读/写提交 |
× |
√ |
√ |
|
可重复读 |
× |
× |
√ |
|
序列化 |
× |
× |
× |
