事务
所谓事务，它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。
事务的ACID特性
数据库事务必须具备ACID特性，ACID是Atomic（原子性）、Consistency（一致性）、Isolation（隔离性）和Durability（持久性）的英文缩写。
- 原子性（Atomic）：组成一个事务的多个数据库操作是一个不可分割的原子单元；只有所有操作执行成功，整个事务才提交，其中一个操作失败，都必须回滚到初始状态。
- 一致性（Consistency）：事务操作成功后数据库所处的状态和它的业务规则是一致的；（即数据总额不会被破坏。如A账户转账100到B账户，无论操作成功与否，A和B的存款总额是不变的）
- 隔离性（Isolation）：在并发数据操作时，不同的事务拥有各自的数据空间，它们的操作不会对彼此产生干扰。（并非是完全无干扰，根据数据库的隔离级别，会产生不同程度的干扰）
- 持久性（Durability）：一旦事务提交成功，事务中的数据操作都必须持久化到数据库中；就算数据库崩溃，也必须保证有某种机制恢复。
在这些特性中，数据“一致性”是最终目标，其他的特性都是为了达到这个目标的措施和手段。
特性实现
事务的（ACID）特性是由关系数据库管理系统（RDBMS，数据库系统）来实现的。数据库管理系统采用日志来保证事务的原子性、一致性和持久性。日志记录了事务对数据库所做的更新，如果某个事务在执行过程中发生错误，就可以根据日志，撤销事务对数据库已做的更新，使数据库退回到执行事务前的初始状态。
数据库管理系统采用锁机制来实现事务的隔离性。当多个事务同时更新数据库中相同的数据时，只允许持有锁的事务能更新该数据，其他事务必须等待，直到前一个事务释放了锁，其他事务才有机会更新该数据。
事务隔离级别
- ISOLATION_DEFAULT：这是一个PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别。
每种数据库的默认隔离级别是不同的，例如SQL Server、Oracle默认Read Commited，MySQL默认Repeatable Read。
另外四个与JDBC的隔离级别相对应，不同的隔离级别采用不同的锁类型来实现，在四种隔离级别中，Serializable的隔离级别最高，Read Uncommited的隔离级别最低。 - ISOLATION_READ_UNCOMMITTED：读未提交数据，这是事务最低的隔离级别，在并发的事务中，它充许一个事务可以读到另一个事务未提交的更新数据。（会出现脏读，不可重复读和幻读）
- ISOLATION_READ_COMMITTED：读已提交数据，保证在并发的事务中，一个事务修改的数据提交后才能被另外一个事务读取到。（会出现不可重复读和幻读）
- ISOLATION_REPEATABLE_READ：可重复读，这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻读。一般是采用“快照”的方式来实现的。
- ISOLATION_SERIALIZABLE：事务被处理为顺序执行。这是花费最高，但也是最可靠的事务隔离级别。能有效的避免脏读、不可重复读、幻读。
查看InnoDB系统级别的事务隔离级别：
SELECT @@global.tx_isolation;
查看InnoDB会话级别的事务隔离级别：
SELECT @@tx_isolation;
脏读、不可重复读、幻读的概念
- 脏读：一个事务读取到另一事务未提交的更新新据。当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据，那么另外一个事务读到的这个数据是脏数据，依据脏数据所做的操作也可能是不正确的。
- 不可重复读：在同一事务中，多次读取同一数据返回的结果有所不同。换句话说就是，后续读取可以读到另一事务已提交的更新数据。相反，“可重复读”在同一事务中多次读取数据时，能够保证所读数据一样，也就是，后续读取不能读到另一事务已提交的更新数据。
- 幻读：事务T1执行一次查询，然后事务T2新插入一行记录，这行记录恰好可以满足T1所使用的查询的条件。然后T1又使用相同的查询再次对表进行检索，但是此时却看到了事务T2刚才插入的新行。这个新行就称为“幻像”，因为对T1来说这一行就像突然出现的一样。
PROPAGATION（事务传播属性）
- PROPAGATION_REQUIRED：支持当前事务，如果当前没有事务，就新建一个事务。也就是说业务方法需要在一个事务中运行，如果业务方法被调用时，调用业务方法的行为（方法）已经处在一个事务中，那么就加入到该事务，否则为自己创建一个新的事务。（默认传播属性）
- PROPAGATION_SUPPORTS：支持当前事务，如果当前没有事务，就以非事务方式执行。也就是说如果业务方法在某个事务范围内被调用，则该方法成为该事务的一部分。如果业务方法在事务范围外被调用，则该方法在没有事务的环境下执行。
- PROPAGATION_MANDATORY：支持当前事务，如果当前没有事务，就抛出异常。也就是说业务方法只能在一个已经存在的事务中执行，业务方法不能发起自己的事务。如果业务方法在没有事务的环境下被调用，容器就会抛出例外。
- PROPAGATION_REQUIRESNEW：新建事务，如果当前存在事务，把当前事务挂起。也就是说业务方法被调用时，不管是否已经存在事务，业务方法总会为自己发起一个新的事务。如果调用业务方法的行为（方法）已经运行在一个事务中，则原有事务会被挂起，新的事务会被创建，直到业务方法执行结束，新事务才算结束，原先的事务才会恢复执行。
- PROPAGATION_NOT_SUPPORTED：以非事务方式执行，如果当前存在事务，就把当前事务挂起。也就是说业务方法不需要事务。如果方法没有被关联到一个事务中，容器不会为它开启事务。如果方法在一个事务中被调用，该事务会被挂起，在方法调用结束后，原先的事务便会恢复执行。
- PROPAGATION_NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。也就是说业务方法绝对不能在事务范围内执行。如果业务方法在某个事务中执行，容器会抛出例外，只有业务方法没有关联到任何事务，才能正常执行。
- PROPAGATION_NESTED：如果一个活动的事务存在，则运行在一个嵌套的事务中。 如果没有活动事务, 则按REQUIRED属性执行。它使用了一个单独的事务， 这个事务拥有多个可以回滚的保存点。内部事务的回滚不会对外部事务造成影响。它只对DataSourceTransactionManager事务管理器起效。
MySQL Innodb 如何避免幻读
对于Innodb，Repeatable Read (RR) 针对当前读，RR隔离级别保证对读取到的记录加锁 (记录锁)，同时保证对读取的范围加锁，新的满足查询条件的记录不能够插入 (间隙锁)，不存在幻读现象。
mysql innodb引擎的实现，跟标准有所不同。
大致意思就是，在 RR 级别下，如果查询条件能使用上唯一索引，或者是一个唯一的查询条件，那么仅加行锁，如果是一个范围查询，那么就会给这个范围加上 gap 锁或者 next-key锁 (行锁+gap锁)。
从这句话的理解来看，和文章里的解释一样，由于 RR 级别对于范围会加 GAP 锁，这个和 sql 的标准是有一些差异的。
MySQL InnoDB的可重复读并不保证避免幻读，需要应用使用加锁读来保证。而这个加锁度使用到的机制就是next-key locks。
最终结论
Innodb 的 RR 隔离界别对范围会加上 GAP，理论上不会存在幻读，但是是否有例外呢，这个还需要进一步求证。
快照读和当前读
在RR级别中，通过MVCC机制，虽然让数据变得可重复读，但我们读到的数据可能是历史数据，是不及时的数据，不是数据库当前的数据！
对于这种读取历史数据的方式，我们叫它快照读 (snapshot read)，而读取数据库当前版本数据的方式，叫当前读 (current read)。
事务原理
事务的实现是基于数据库的存储引擎。不同的存储引擎对事务的支持程度不一样。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中记录的日志，把数据库恢复到崩溃前的一个状态。未完成的事务，可以继续提交，也可以选择回滚，这基于恢复的策略而定。
undo log
undo log主要为事务的回滚服务。在事务执行的过程中，除了记录redo log，还会记录一定量的undo log。undo log记录了数据在每个操作前的状态，如果事务执行过程中需要回滚，就可以根据undo log进行回滚操作。单个事务的回滚，只会回滚当前事务做的操作，并不会影响到其他的事务做的操作。
所以，redo log其实保障的是事务的持久性和一致性，而undo log则保障了事务的原子性。
分布式事务
分布式事务的实现方式有很多，既可以采用innoDB提供的原生的事务支持，也可以采用消息队列来实现分布式事务的最终一致性。这里我们主要聊一下innoDB对分布式事务的支持。
MySQL的分布式事务模型。模型中分三块：应用程序（AP）、资源管理器（RM）、事务管理器（TM）。
• 应用程序定义了事务的边界，指定需要做哪些事务；
• 资源管理器提供了访问事务的方法，通常一个数据库就是一个资源管理器；
• 事务管理器协调参与了全局事务中的各个事务。
分布式事务采用两段式提交（two-phase commit）的方式。
• 第一阶段所有的事务节点开始准备，告诉事务管理器ready。
• 第二阶段事务管理器告诉每个节点是commit还是rollback。
如果有一个节点失败，就需要全局的节点全部rollback，以此保障事务的原子性。
来自：http://www.cnblogs.com/zhiqian-ali/p/5668199.html
参考资料
数据库 事务的特性ACID
mysql隔离级别及事务传播
五分钟搞清楚MySQL事务隔离级别