# 为什么需要事务呢？ 在[数据库（二），数据库起源](http://www.cnblogs.com/dy2903/p/8365376.html)里面我们提到了事务。 数据库除了对查询等操作进行了抽象，另外一个重要的功能就是**事务**了。为什么需要事务呢？因为我们在操作数据的时候，可能遇到多个线程同时操作数据的问题，也可能遇到突然数据库故障了的问题，这些都可能造成数据的**不一致**。所以事务要保证的就是**一致性**。 保证一致性的第一重意思是**锁**，这是为了应对多个**连接**同时连到数据库的时候。因为我们可能为每个连接分配一个线程，而这些线程有可能同时操作同一块数据，这样将会发生**不一致**。所以我们只好在写的时候加上**锁**，也就是强行保证只有一个线程可以访问到这块数据。 另外我们还会遇到数据库崩溃的问题，所以我们要求一个事务一定是**原子**的，也就是 **要么全部发生， 要么根本不发生。**比如Bob给Smith转100块，要么Bob有100块，要么Smith有100块，不存在中间状态。 对于单机事务而言，需要保证 - 原子性 - 一致性 - 隔离性 - 持久性 也就是所谓的ACID，下面我们依次介绍他们是怎么实现的。  # 原子性 ## Undo日志 所谓**原子性**指的是要么同时成功，要么同时失败。比如Bob账户里面有100块，而Smith账户里面有0元，现在我们希望Bob转100块给Smith。 所谓**原子性**就是要么Bob成功转给了Smith100块，此时Bob有0元、Smith有100块。要么失败了，Bob仍然有100块，Smith为0元。**不会存在Bob把钱转出去了，而Smith却没有拿到钱的情况。** 现在我们来想想要实现这个事务，应该怎么做 - 锁定Bob账户 - 锁定Smith账户 - 查看Bob是否有100块钱，如果有，则从账号里面减少100块 - 给Smith账户里面增加100块 - 依次解锁Bob和Smith  但是执行事务不会永远是一帆风顺的，可能出现**意外**，比如Bob或者Smith账户不存在怎么办？没关系，我们可以**回滚**到上一个状态。 但是数据库不可能把每个状态都记录下来，这就需要我们在转账之前把**之前的状态**记录下来。 比如我们看刚刚那个转账操作的**中间状态** 1. Bob：100，Smith：0 2. Bob：0，Smith ：0 （此时正在转账） 3. Bob ： 0 ， Smith ：100（转账成功） 我们可以在插入两个undo段，他们记录在日志中。 1. Bob：100，Smith：0 2. Bob：0，Smith ：0 （此时正在转账） - 上一个状态为：Bob：100，Smith：0 3. Bob ： 0 ， Smith ：100（转账成功） - 上一个状态为： Bob：0，Smith ：0 这样如果要回滚，只需要回溯日志即可实现。这 **另外还有一种可能就是事务并没有进行完，系统就崩溃了怎么办？**那系统重启之后就得做**恢复**操作啊。那怎么恢复了，同样也是通过**日志**。我们可以在进行真正的操作之前，需要把要做的事写下来， 我们会在事务开始之前写下： > Bob原有100元，Smith原有0元 如果事务执行到一半就断电，那么重启之后我们就可以按照**日志来恢复**，然后仍然是** Bob有100元，Smith有0元**。即使恢复100次，仍然是这个结果，这就叫**幂等性**，所以恢复过程中也断电了，我们仍然可以按照日志来进行恢复。 现在还有个一问题没有解决，那就是怎么知道**一个事务没有完成呢？** 同样我们可以通过记录日志的方式来完成。比如我们在记录的时候，不但把余额记上，还把**事务开始了和结束**这两个动作打上标记。 比如 > [开始事务T1] [事务T1：Bob原有100] [事务T2：Smith原有0] [提交事务T1] 这样，如果在日志中看到了**提交事务T1**或者**回滚事务T1**，我们就知道这个事务已经结束了。如果只看到**开始事务T1**，那就得恢复。比如下面这个就得恢复 > [开始事务T1] [事务T1：Bob原有100] [事务T2：Smith原有0] 而且，在**恢复之后**，需要在日志文件中加上一行**回滚事务T1**，这样下次恢复就不用再考虑T1这个事务呢，因为现在早已经回到上一个状态去了呢。 ## Undo日志写入文件的时机 上面的讨论其实我们都故意忽略了一个问题，那就是Undo日志也需要加载到内存中才能读写，但是如果日志还没写好就断电了怎么办？ **其实我们只要掌握好把日志写入文件的时机就OK了。** 最容易想到的就是在一开始就把日志写入文件，就好比写作文前把草稿打好，后面只管按着草稿誊抄一遍就可以了。 然而，现实是，一开始的时候，我们都不知道程序要操作哪个字段，怎么记录日志呢，当然也不能写入文件呢。所以肯定是一边在内存中操作Undo日志，一边找时机写入磁盘中。 比如上面的转账操作，我们其实可以这样来修改和写日志。 |操作|数据缓冲区|日志缓冲区| |:--|:--|:--| |开始事务T1||[开始事务T1]| |Bob = Bob - 100 |Bob新余额为0|[事务T1，Bob原有余额为100]| |把日志写入文件||注意，日志写入文件后，缓冲区会清空| |把Bob余额写入文件||| |Smith = Smith + 100||[事务T1，Smith原有余额0]| |把日志写入文件||注意，日志写入文件后，缓冲区会清空| |把Smith余额写入文件|Smith新余额为100|| |提交事务T1||[提交事务T1]| |把日志写入文件||注意，日志写入文件后，缓冲区会清空| 总结一下就是， - 当余额发生改变的时候，记录之前的余额 - 在余额要写入硬盘之前，需要把日志先写入文件，然后日志缓冲区会清空。 - 提交事务的日志一定是在所有余额都写入硬盘之后才写入 也就是说事务过程中，余额发生改变，在余额正式写入了硬盘以后，相当于木已成舟，所以我们也需要把日志写入硬盘。 当所有余额都稳稳当当的落到磁盘上了，我们自然也应该把日志落到磁盘上 那么我们可以攻防演练一下。 如果Bob的余额写到了硬盘，但是Smith还没修改。此时日志中落盘的只有Bob原有的余额也就是： > [开始事务T1] [事务T1：Bob原有100] 恢复的时候，发现事务没有结束，所以还会把Bob的余额给恢复了。 同理，如果Bob和Smith的余额都落盘了，但是没有提交事务，此时日志是 > [开始事务T1] [事务T1：Bob原有100] [事务T2：Smith原有0] 依然可以恢复两个账户的余额。 即使两个账户的最新余额都落盘了，也提交了事务，但是只要在日志写入磁盘之前崩溃，则Undo日志还是 > [开始事务T1] [事务T1：Bob原有100] [事务T2：Smith原有0] 同样会把余额恢复成原样。 ## 原子性做不到的地方 现在可算是把原子性说完了，但是只有原子性是不够的，为什么呢？因为它无法保证多个线程访问数据时的一致性。 比如在第2步的时候，另一个事务把把smith账户加到了300块钱， 1. Bob：100，Smith：0 2. Bob：0，Smith ：0 ------------->Bob：0，Smith ：300（另一个事务干的） - 上一个状态为：Bob：100，Smith：0 3. Bob ： 0 ， Smith ：100（转账成功） - 上一个状态为： Bob：0，Smith ：0 如果有另一个事务在进行到步骤2的时候把smith账户加到了300块钱，此时如果回滚，会把smith改为0，那加上的300块就丢失了。 那么我们还需要一致性。  # 一致性 上一章我们提到了如果在事务中间，有另一个事务突然插手对数据进行修改，则如果出现回退，将会出现数据不一致的问题。 那怎么解决这个问题呢？如果我们一个事务对数据操作完了以后，另一个事务再进入，这样就不会发生争抢和数据不一致了。所以核心就在于**加锁**。 比如 - Lock Bob , Smith 1. Bob：100，Smith：0 2. Bob：0，Smith ：0 ------------->Bob：0，Smith ：300（另一个事务干的） - 上一个状态为：Bob：100，Smith：0 3. Bob ： 0 ， Smith ：100（转账成功） - 上一个状态为： Bob：0，Smith ：0 - unLock Bob and Smith 在事务的开始和结束分别进行加锁和解锁。这样，其他的事务并不可知事务内部的事情。只有在**事务单元内部完全成功了以后才对外可见。** 到现在我们“仿佛”已经解决了**并发、一致**两个大问题了，但是新的问题也来了，**加锁**以后，其他的事务无法对数据进行访问，那么**系统的并发度**是上不来的，这就是下面的**隔离性**要解决的问题。  # 隔离性 所谓**隔离性**，其实是以性能作为理由，在破坏**一致性**。何以见得？因为如果要保证强一致性，最好的方法就是不管读写，统统排队进行，这样一定不会出现数据不一致的情况。 然而此时就做不到高的并发，性能也就上不去。所以我们只要做一些妥协，比如只加写锁，不加读锁。 我们首先需要看看，两个事务单元对同一个数据，有哪几种并发模式，然后定义不同的隔离级别，看每种隔离级别可以实现哪些并发模式。 ## 4种可能 同样我们以一个例子来说明 现在 T1 ：Bob要给Smith 100块，然后T2 ： Smith要给Joe 100块。 这就是两个事务，如下图所示，为了保证一致性，Smith账户会被两个事务单元锁定。也就是两个事务有共享数据，Bob在给Smith转钱的时候，另一个事务无法对Smith账户进行操作了，并发就上不去。  此时两个事务单元T1，T2之间只有**读写并发、写读并发、读读并发、写写并发**4种可能。 - 写写并行 什么时候能写写并行，只有当两个事务的数据完全没有重叠的情况下，比如如下的情况。  因为没有共享数据，所以完全可以**写写**并行，也就是写写都不加锁。 - 读读并行 也就是读操作不加锁，这样读与读可以并行操作，因为读不会修改数据，所以读读可以放心的并行，而不用担心一致性的问题。  - 读写并行 也就是读的时候，可以并发写。我们知道，写操作会修改数据，但是写是加锁的，所以我们无法读到写未提交的结果。所以虽然两次读到的数据是不一样的，**不可重复读**，但是每次读到的数据都是正确的，不存在不一致。 - 写读并行 也就是写的时候，还可以并发读。因为数据是在不断改变的，很可能读到中间的状态，如果系统在此时崩溃了，重启的时候会恢复到修改前的值，此时自然会出现错乱。 那么我们是否无法实现写读并行了吗？并不是，可以通过Copy on Write。具体怎么做呢？每次写操作之前都把数据复制一份到log里面，在log里面进行修改。 其实就是把原来的数据复制一份，然后修改。这样读操作作用的就是原来的数据，而写作用的是备份的数据，互不干扰。  这种方法又叫（MVCC，Multi Version content control，多版本内容控制）。那么**多版本**是什么意思。 我们知道数据被复制出去了一份以后，可能会被修改多次，那么**下一次读应该读修改后哪个版本的数据呢？**这个时候，我们可以在日志里面加上**版本号**。比如说，现在写入的数据版本号是10，如果要读取版本号为5的数据，则可以往前一直找，直到找到对应的位置。 所以如果读发生在写操作之后，**读的版本号一定要大于写的版本号。**这样就可以保证读到想要的数据。 ## 四种隔离级别 上面讲了两个事务单元针对一块数据其实有4种并发的可能，接下来我们继续讨论**隔离级别**。不同的隔离级别可以实现**读写并行、写读并行、读读并行、写写并行**的一种或者几种。 - 串行化： 就是读的时候不允许写，写的时候不允许读，这样可以保证数据强一致，但是性能最低。SQLite默认采用这种方式。  - 可重复读，也就是只能实现**读读并行**，**读写、写读、写写**等不能实现。 所以在两个都是读的时候，不加读锁，其他情况均需要加锁。 MySQL默认是这种方式。 - 读已提交(Read Committed)： 此时当数据被加上读锁了以后，一个写进来，写锁替换掉读锁，也就是**可以将读锁升级为写锁。** 那么如果事务T1读取了数据，然后事务T2把这个数据修改了，因为事务T2也是加锁的，所以它会提交，那么事务T1**再读取**这个数据时，原来的数据已经发生变化了。这就是不可重复读。  此时可以做到**读写并行、读读并行**，做不了**写读并行** Oracle , PostgreSQL, SQL Server都是使用的这种模式。 - 读未提交：顾名思义，就是可以读到未提交的内容 最低级别的隔离，此时只加上**写和读是不加锁的**。因为数据是在不断改变的，很可能读到中间的状态，如果系统在此时崩溃了，重启的时候会恢复到修改前的值，此时自然会出现错乱。  要解决**写读并行**的问题，可以使用上面说过的Copy on write，这种方法最大的好处在于可以保证写读并行，同时隔离级别还很高  # 持久性 现在我们来讨论最后ACID的**持久性**，也就是**只要事务提交了，不管是崩溃还是出错，数据一定要写到磁盘上** 那么数据什么情况下会丢失呢？ - 首先是磁盘损坏。所以我们可以使用RAID冗余磁盘阵列来保证可靠性。详见[【大话存储】学习笔记（4，5章），RAID](http://www.cnblogs.com/dy2903/p/8417836.html) - 还有就是内存如果掉电，里面的数据就必然丢失，持久性得不到保证。但是如果每一次提交操作完成以后，都将内存中的数据同步到硬盘上，则会造成频繁写硬盘，性能将下降。所以**持久性和延迟无法兼得** 我们只要进行折中，比如只要把数据提交到**内存**，就立刻返回成功，然后将一段时间的请求**打包**送到磁盘上。这样就避免了每次提交都写磁盘  # 参考 - 慕课网 - 如果有人问你数据库的原理，叫他看这篇文章[如果有人问你数据库的原理，叫他看这篇文章](http://blog.csdn.net/xmric/article/details/54972998)