前些日子读了周志明老师的《凤凰架构》这本书，对于很多方面的技术有了更深的认知，因此打算做一些总结。今天先以讲事务的这一段做个印子，结合书中内容和个人理解，争取将本地事务的相关知识讲个命名白白。如果有讲的不对的地方，欢迎大家多多指正。
所谓事务，就是保证数据库中的数据都是符合期望的，在不断的增删改查中，数据库会不断的从一个正确的状态变化到另一个正确的状态，而不会被外界感知到不“正确”的中间状态。
举个常见的例子，就是在 A有100元，B有100元的状态下，A要给B转账10元，肯定会有A先转出10元，再转给B,这样的中间状态。事务就是，对于用户来说，只能感知到 A100 B100 和 A90 B110 这两个状态，而不会感知到过程中的A90 B100等等奇奇怪怪的状态。
这个介绍，其实也就是事务ACID特性中一致性的概念。ACID这个说法虽然很流行，但A、C、I、D之间其实并不是平等的概念，简单来说，AID是方法，C是目的。也就是说，实现了原子性、持久性、隔离性，也就实现了一致性，也就实现了事务。
接下来，我们就依次看看AID分别要如何实现。
原子性和持久性
实现原子性和持久性面临的相同问题其实挺多的，所以把它们放在一起介绍。
先复习一下基本概念，所谓原子性，就是事务内的操作要么都成功，要么都失败；所谓持久性，就是已经完成的操作不会丢失。
值得说明的是，单纯的“实现原子性和持久性”并不存在任何难度，要讨论的问题其实是“如何更高性能的实现原子性和持久性”，（后面要说的隔离性也是一个概念，只有高性能的隔离性才有意义）。
其中一个关键点在于，写磁盘是一个非常重的操作，所以通常会存在一个内存缓冲区，要写磁盘的数据会先写到缓冲区里，再择机落盘。那么假如在事务已提交而尚未落盘的这个时间点，系统出现故障，那么这部分未落盘的数据自然就会丢失，数据库也就失去了持久性。针对这个问题，一个很自然的想法就是事务提交的时候强制刷盘。这个方案可不可行？当然是可行的。但它的问题就是会影响性能。系统出故障毕竟是小概率事件，为了处理这个小概率事件，相当于所有操作都要额外付出一些代价。
实际上为了解决这个问题，一个常规的处理思路就是使用一个commit Log, 也就是在实际写数据之前，先将所有要修改的信息记录在一个log里，如果出现上面描述的问题，系统重启时，会先根据commit log进行数据恢复。而由于写这份log是一个顺序写磁盘的操作，性能会远远好于随机写磁盘，所以这个方式的性能是没有问题的。在数据真正写入之后，再加一个标记，表示这条log已经完成了持久化。
接下来，我们再看一下commit log是否还有优化空间？自然是有的。Commit log的一个重要缺陷就是所有真实的磁盘操作都必须发生在事务提交之后。假如说这个事务非常大，就会占用很大的内存缓冲区，这也会影响系统的性能。改进方案是 write-ahead log 这个机制，这个机制我在之前的文章(https://lichuanyang.top/posts/3914/)里也介绍过，和commit log其实非常像，也是先顺序写一个log文件，唯一的区别就是write-ahead log允许在事务提交之前写入。mysql里的redo log，其实就是一个典型的write-ahead log实现。
讲到这里，我们先暂停一下，回顾一下上面的内容，会发现上边其实基本都在说持久性，原因是对于上边的机制来说，原子性其实都是自然而然的事情，commit log写进去了，这条事务就相当于完成了；commit log没写入，这个事务就相当于不存在。但是使用了write-ahead log的话，情况就不一样了，一个事务会涉及多次磁盘写入，所以也就不满足原子性了。因此，需要引入别的机制来保证原子性，undo log就是实现这个目标的一个典型思路。当变动数据写入磁盘前，必须先记录undo log，注明修改了哪个位置的数据、从什么值改成什么值等，以便在事务回滚或者崩溃恢复时根据undo log对提前写入的数据变动进行擦除。
像在mysql中，实际上也就是像我们上边讲的那样，利用redo log和undo log实现高效可靠的持久性和原子性。
隔离性
如何实现不同事务之间的隔离，一个很自然的思路就是加锁，实际上常规的数据库实现也就是这么做的。一般来说，有这么几种类型的锁：读锁（也叫共享锁），写锁（也叫排他锁），范围锁。
对于一条数据，只有一个事务能持有写锁；不同的事务可以同时持有读锁，数据被添加读锁后不能再添加写锁, 添加写锁后也不能再添加读锁；范围锁则是对一个范围加写锁，在这个范围内都不能写入数据。
我们知道，数据库有四种常见的隔离级别：可串行化，可重复读，读已提交，读未提交。其区别其实就是加锁粒度的不同。
如果我们把所有操作能加的锁都加上，实际上就是串行化的操作了。这种方式隔离性当然很好，但性能就没法说了，所以一般也不会有人使用。
可重复读则是对涉及到的数据加读锁和写锁，并持有到事务结束，但不会加范围锁。这样就会出现幻读的问题，即一个事务内执行两次范围查询，如果这两次查询之间有新的数据被插入，就会导致两次范围查询的结果不一致。
读已提交和可重复读的区别是他的读锁会在查询操作结束之后立刻释放掉，这样，在事务执行过程中，已经查询过的数据是可以被其他事务任意修改的，所以也就会有不可重复读的问题。
读未提交级别下，则完全不会加读锁。这样造成的问题是，由于读操作时不会去申请读锁，所以反而会导致能够读到其他事务上加了写锁的数据，也就会出现脏读的问题。
其实说到底，隔离性和性能就是一对相互矛盾的需求。加锁加的越多，隔离性自然越好，性能也自然越差。我们需要根据实际的使用场景来决定锁究竟要加到什么程度。
而另一个思路，则是再看看有没有锁以外的方式，考虑28原则，看看有没有什么办法，牺牲20%的性能去解决80%的问题。具体来讲，涉及隔离性问题的场景，其实可以简化为一个读事务+一个写事务，和两个写事务，这两种场景。大部分场景下，当然是读+写的情况更多，所以我们找个方式去解决读+写场景下的幻读问题。相信很多人已经猜到了，这种方式就是MVCC。关于MVCC, 网上介绍资料实在太多，我们就不再赘述了。
经过上面对于事务几个特性的介绍，相信大家已经对本地事务有了非常深刻的认识。如有问题，欢迎留言讨论。下一篇文章，我会继续讲一下分布式事务的相关知识，如果感兴趣，可以关注我的个人博客、知乎或者公众号追更~