剑指架构师系列-InnoDB存储引擎、Spring事务与缓存

事务与锁是不同的。事务具有ACID属性：

原子性:持久性：由redo log重做日志来保证事务的原子性和持久性,
一致性：undo log用来保证事务的一致性
隔离性:一个事务在操作过程中看到了其他事务的结果，如幻读。锁是用于解决隔离性的一种机制。事务的隔离级别通过锁的机制来实现。

数据库的事务隔离级别有（多个事务并发的情况下）：

√: 可能出现    ×: 不会出现

事务的隔离级别	脏读  事务1更新了记录，但没有提交，事务2读取了更新后的行，然后事务T1回滚，现在T2读取无效。违反隔离性导致的问题，添加行锁实现	不可重复读  事务1读取记录时，事务2更新了记录并提交，事务1再次读取时可以看到事务2修改后的记录（修改批更新或者删除）需要添加行锁进行实现	幻读   事务1读取记录时事务2增加了记录并提交，事务1再次读取时可以看到事务2新增的记录。需要添加表锁进行实现
Read uncommitted	√	√	√
Read committed	×	√	√
Repeatable read	×	×	√
Serializable	×	×	×

注意点：

 

（1）要分清不可重复读和幻读的区别 一个是更新记录，另外一个是读取了新增的记录

 

（2）不同的数据库存储引擎其实并没有严格按照标准来执行，如innodb默认的repeatable read隔离级别下就可以做到避免幻读的问题（采用了Next-Key-Lock锁的算法）

 

 

对应着Spring中的5个事务隔离级别（通过lsolation的属性值指定）

1、default   默认的事务隔离级别。使用的是数据库默认的事务隔离级别

2、read_uncommitted  读未提交，一个事务可以操作另外一个未提交的事务，不能避免脏读，不可重复读，幻读，隔离级别最低，并发性能最高

3、read_committed（脏读）  大多数数据库默认的事务隔离级别。读已提交，一个事务不可以操作另外一个未提交的事务， 能防止脏读，不能避免不可重复读，幻读

4、repeatable_read（不可重复读） innodb默认的事务隔离级别。能够避免脏读，不可重复读，不能避免幻读

5、serializable（幻读） innodb存储引擎在这个级别才能有分布式XA事务的支持。隔离级别最高，消耗资源最低，代价最高，能够防止脏读， 不可重复读，幻读

Spring中的事务完全基于数据库的事务，如果数据库引擎使用MyISAM引擎，那Spring的事务其实是不起作用的。另外，Spring为开发者提供的与事务相关的特性就是事务的传播行为，如下：

事务传播行为类型	说明
propagation_required	如果当前没有事务，就新建一个事务，如果已经存在一个事务中，加入到这个事务中。这是最常见的选择（Spring默认的事务传播行为）
propagation_supports	支持当前事务，如果当前没有事务，就以非事务方式执行
propagation_mandatory(托管）	使用当前的事务，如果当前没有事务，就抛出异常
propagation_requireds_new	新建事务，如果当前存在事务，把当前事务挂起
propagation_not_supported	以非事务方式执行操作，如果当前存在事务，就把当前事务挂起
propagation_never	以非事务方式执行，如果当前存在事务，则抛出异常
propagation_nested	如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与propagation_required类似的操作，也就是新建一个事务

Spring通过事务传播行为控制当前的事务如何传播到被嵌套调用的目标服务接口方法中。

Spring可以配置事务的属性，但是隔离级别、读写事务属性、超时时间与回滚设置等都交给了JDBC，真正自己实现的只有事务的传播行为。那么什么时候发生事务的传播行为呢？

public class ForumService {
	private UserService userService;

	@Transactional(propagation = Propagation.REQUIRED)
	public void addTopic() {
		// add Topic
		this.updateTopic();
		userService.addCredits();
	}

	@Transactional(propagation = Propagation.REQUIRED)
	public void updateTopic() {
		// add Topic
	}

	public void setUserService(UserService userService) {
		this.userService = userService;
	}
}

看一下userService中的addCredits()方法，如下：

public class UserService {

	@Transactional(propagation = Propagation.REQUIRES_NEW)
	public void addCredits() {

	}
}

然后测试下：

forumService.addTopic();

开启了Spring4日志的DEBUG模式后，输出如下：　　

　

 - Returning cached instance of singleton bean 'txManager'
 - Creating new transaction with name [com.baobaotao.service.ForumService.addTopic]: PROPAGATION_REQUIRED,ISOLATION_DEFAULT; ''
 - Acquired Connection [org.apache.commons.dbcp.PoolableConnection@1948ea69] for JDBC transaction
 - Switching JDBC Connection [org.apache.commons.dbcp.PoolableConnection@1948ea69] to manual commit
 - Suspending current transaction, creating new transaction with name [com.baobaotao.service.UserService.addCredits]
 - Acquired Connection [org.apache.commons.dbcp.PoolableConnection@773e2eb5] for JDBC transaction
 - Switching JDBC Connection [org.apache.commons.dbcp.PoolableConnection@773e2eb5] to manual commit
 - Initiating transaction commit
 - Committing JDBC transaction on Connection [org.apache.commons.dbcp.PoolableConnection@773e2eb5]
 - Releasing JDBC Connection [org.apache.commons.dbcp.PoolableConnection@773e2eb5] after transaction
 - Returning JDBC Connection to DataSource
 - Resuming suspended transaction after completion of inner transaction
 - Initiating transaction commit
 - Committing JDBC transaction on Connection [org.apache.commons.dbcp.PoolableConnection@1948ea69]
 - Releasing JDBC Connection [org.apache.commons.dbcp.PoolableConnection@1948ea69] after transaction
 - Returning JDBC Connection to DataSource

清楚的看到只有调用addCredis()方法时发生了事务的传播行为，而同一个类内的方法没有发生。在我们阅读了源代码后就可以知道这是为什么以及什么时候会发生传播行为了。

另外一点：决定事务传播行为是由首次调用有事务的方法决定的。如上例子中的事务传播行为由addTopic()方法来决定。

在使用事务中我们需要做到尽量避免死锁、尽量减少阻塞，根据不同的数据库设计和性能要求进行所需要的隔离级别，才是最恰当的。具体以下方面需要特别注意：

A、 事务操作过程要尽量小，能拆分的事务要拆分开来

B、 事务操作过程不应该有交互（系统交互，接口调用），因为交互等待的时候，事务并未结束，可能锁定了很多资源

C、 事务操作过程要按同一顺序访问对象。（避免死锁的情况产生）

D、 提高事务中每个语句的效率，利用索引和其他方法提高每个语句的效率可以有效地减少整个事务的执行时间。

E、 查询时可以用较低的隔离级别，特别是报表查询的时候，可以选择最低的隔离级别（未提交读）。