标签：
最近一直在做订单类的项目，使用了事务。我们的数据库选用的是MySQL，存储引擎选用innoDB，innoDB对事务有着良好的支持。这篇文章我们一起来扒一扒事务相关的知识。
事务广泛的运用于订单系统、银行系统等多种场景。如果有以下一个场景：A用户和B用户是银行的储户。现在A要给B转账500元。那么需要做以下几件事：
1. 检查A的账户余额>500元； 2. A账户扣除500元； 3. B账户增加500元；
正常的流程走下来，A账户扣了500，B账户加了500，皆大欢喜。那如果A账户扣了钱之后，系统出故障了呢？A白白损失了500，而B也没有收到本该属于他的500。以上的案例中，隐藏着一个前提条件：A扣钱和B加钱，要么同时成功，要么同时失败。事务的需求就在于此。
与其给事务定义，不如说一说事务的特性。众所周知，事务需要满足ACID四个特性。
前文中提到，事务的隔离性受到隔离级别的影响。那么事务的隔离级别是什么呢？
事务的隔离级别可以认为是事务的"自私"程度，它定义了事务之间的可见性。隔离级别分为以下几种：
为了帮助理解四种隔离级别，这里举个例子。如图1，事务A和事务B先后开启，并对数据1进行多次更新。四个小人在不同的时刻开启事务，可能看到数据1的哪些值呢？
第一个小人，可能读到1-20之间的任何一个。因为未提交读的隔离级别下，其他事务对数据的修改也是对当前事务可见的。第二个小人可能读到1，10和20，他只能读到其他事务已经提交了的数据。第三个小人读到的数据去决于自身事务开启的时间点。在事务开启时，读到的是多少，那么在事务提交之前读到的值就是多少。第四个小人，只有在A end 到B start之间开启，才有可能读到数据，而在事务A和事务B执行的期间是读不到数据的。因为第四小人读数据是需要加锁的，事务A和B执行期间，会占用数据的写锁，导致第四个小人等待锁。
疑问：当第三个小人从A执行过程中开始执行，直到事务B提交后提交，那看到的是1还是10，一直都是1？按照提交读貌似他只可以读到1，但是按照可重复读又可以读到10的样子。。。到底是怎么回事呢？
其实需要明确，RR级别一定是可以读到事务开启时已经提交的事务，未提交的当然也看不到，不然一样存在不可重复读，只是这个保障通过MVCC去实现。(如有疏漏，望君指正)
图2 罗列了不同隔离级别所面对的问题。
很显然，隔离级别越高，它所带来的资源消耗也就越大(锁)，因此它的并发性能越低。准确的说，在可串行化的隔离级别下，是没有并发的。
事务的实现是基于数据库的存储引擎。不同的存储引擎对事务的支持程度不一样。MySQL中支持事务的存储引擎有innoDB和NDB。innoDB是MySQL默认的存储引擎，默认的隔离级别是RR，并且在RR的隔离级别下更进一步，通过多版本并发控制（MVCC，Multiversion Concurrency Control ）解决不可重复读问题，加上间隙锁（也就是并发控制）解决幻读问题。因此innoDB的RR隔离级别其实实现了串行化级别的效果，而且保留了比较好的并发性能。 事务的隔离性是通过锁实现，而事务的原子性、一致性和持久性则是通过事务日志实现。说到事务日志，不得不说的就是redo和undo。
redo log
在innoDB的存储引擎中，事务日志通过重做(redo)日志和innoDB存储引擎的日志缓冲(InnoDB Log Buffer)实现。事务开启时，事务中的操作，都会先写入存储引擎的日志缓冲中，在事务提交之前，这些缓冲的日志都需要提前刷新到磁盘上持久化，这就是DBA们口中常说的“日志先行”(Write-Ahead Logging)。
当事务提交之后，在Buffer Pool中映射的数据文件才会慢慢刷新到磁盘。此时如果数据库崩溃或者宕机，那么当系统重启进行恢复时，就可以根据redo log中记录的日志，把数据库恢复到崩溃前的一个状态。未完成的事务，可以继续提交，也可以选择回滚，这基于恢复的策略而定。
在系统启动的时候，就已经为redo log分配了一块连续的存储空间,以顺序追加的方式记录Redo Log,通过顺序IO来改善性能。所有的事务共享redo log的存储空间，它们的Redo Log按语句的执行顺序，依次交替的记录在一起。如下一个简单示例：
记录1：<trx1, insert...>
记录2：<trx2, delete...>
记录3：<trx3, update...>
记录4：<trx1, update...>
记录5：<trx3, insert...>
undo log
undo log主要为事务的回滚服务。在事务执行的过程中，除了记录redo log，还会记录一定量的undo log。undo log记录了数据在每个操作前的状态，如果事务执行过程中需要回滚，就可以根据undo log进行回滚操作。单个事务的回滚，只会回滚当前事务做的操作，并不会影响到其他的事务做的操作。
以下是undo+redo事务的简化过程：
假设有2个数值，分别为A和B,值为1，2
1. start transaction;
2. 记录 A=1 到undo log;
3. update A = 3；
4. 记录 A=3 到redo log；
5. 记录 B=2 到undo log；
6. update B = 4；
7. 记录B = 4 到redo log；
8. 将redo log刷新到磁盘
9. commit
在1-8的任意一步系统宕机，事务未提交，该事务就不会对磁盘上的数据做任何影响。如果在8-9之间宕机，恢复之后可以选择回滚，也可以选择继续完成事务提交，因为此时redo log已经持久化。若在9之后系统宕机，内存映射中变更的数据还来不及刷回磁盘，那么系统恢复之后，可以根据redo log把数据刷回磁盘。
所以，redo log其实保障的是事务的持久性和一致性，而undo log则保障了事务的原子性。
分布式事务的实现方式有很多，既可以采用innoDB提供的原生的事务支持，也可以采用消息队列来实现分布式事务的最终一致性。这里我们主要聊一下innoDB对分布式事务的支持。
如图，MySQL的分布式事务模型。模型中分三块：应用程序（AP）、资源管理器（RM）、事务管理器（TM）。
分布式事务采用两段式提交（two-phase commit）的方式。
如果有一个节点失败，就需要全局的节点全部rollback，以此保障事务的原子性。
什么时候需要使用事务呢？我想，只要业务中需要满足ACID的场景，都需要事务的支持。尤其在订单系统、银行系统中，事务是不可或缺的。
这篇文章主要介绍了事务的特性，以及MySQL innoDB对事务的支持。事务相关的知识远不止文中所说，本文仅作抛砖引玉，不足之处还望读者多多见谅。
标签：
原文地址：http://www.cnblogs.com/zhiqian-ali/p/5668199.html
