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