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

Posted 2020-10-06

 

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

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

 

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

1、read uncommitted

#首先，修改隔离级别
set tx_isolation=‘READ-UNCOMMITTED‘;
select @@tx_isolation;
+------------------+
| @@tx_isolation   |
+------------------+
| READ-UNCOMMITTED |
+------------------+

#事务A：启动一个事务
start transaction;
select * from tx;
+------+------+
| id   | num  |
+------+------+
|    1 |    1 |
|    2 |    2 |
|    3 |    3 |
+------+------+

#事务B：也启动一个事务(那么两个事务交叉了)
       在事务B中执行更新语句，且不提交
start transaction;
update tx set num=10 where id=1;
select * from tx;
+------+------+
| id   | num  |
+------+------+
|    1 |   10 |
|    2 |    2 |
|    3 |    3 |
+------+------+

#事务A：那么这时候事务A能看到这个更新了的数据吗?
select * from tx;
+------+------+
| id   | num  |
+------+------+
|    1 |   10 |   --->可以看到！说明我们读到了事务B还没有提交的数据
|    2 |    2 |
|    3 |    3 |
+------+------+

#事务B：事务B回滚,仍然未提交
rollback;
select * from tx;
+------+------+
| id   | num  |
+------+------+
|    1 |    1 |
|    2 |    2 |
|    3 |    3 |
+------+------+

#事务A：在事务A里面看到的也是B没有提交的数据
select * from tx;
+------+------+
| id   | num  |
+------+------+
|    1 |    1 |      --->脏读意味着我在这个事务中(A中)，事务B虽然没有提交，但它任何一条数据变化，我都可以看到！
|    2 |    2 |
|    3 |    3 |
+------+------+

　

2、read committed

#首先修改隔离级别
set tx_isolation=‘read-committed‘;
select @@tx_isolation;
+----------------+
| @@tx_isolation |
+----------------+
| READ-COMMITTED |
+----------------+

#事务A：启动一个事务
start transaction;
select * from tx;
+------+------+
| id   | num  |
+------+------+
|    1 |    1 |
|    2 |    2 |
|    3 |    3 |
+------+------+

#事务B：也启动一个事务(那么两个事务交叉了)在这事务中更新数据，且未提交
start transaction;
update tx set num=10 where id=1;
select * from tx;
+------+------+
| id   | num  |
+------+------+
|    1 |   10 |
|    2 |    2 |
|    3 |    3 |
+------+------+

#事务A：这个时候我们在事务A中能看到数据的变化吗?
select * from tx; ------------->
+------+------+                |
| id   | num  |                |
+------+------+                |
|    1 |    1 |--->并不能看到！  |
|    2 |    2 |                |
|    3 |    3 |                |
+------+------+                |——>相同的select语句，结果却不一样
                               |
#事务B：如果提交了事务B呢?        |
commit;                        |
                               |
#事务A:                         |
select * from tx; ------------->
+------+------+
| id   | num  |
+------+------+
|    1 |   10 |--->因为事务B已经提交了，所以在A中我们看到了数据变化
|    2 |    2 |
|    3 |    3 |
+------+------+

　　

3、repeatable read

#首先，更改隔离级别
set tx_isolation=‘repeatable-read‘;
select @@tx_isolation;
+-----------------+
| @@tx_isolation  |
+-----------------+
| REPEATABLE-READ |
+-----------------+

#事务A：启动一个事务
start transaction;
select * from tx;
+------+------+
| id   | num  |
+------+------+
|    1 |    1 |
|    2 |    2 |
|    3 |    3 |
+------+------+

#事务B：开启一个新事务(那么这两个事务交叉了) 在事务B中更新数据，并提交
start transaction;
update tx set num=10 where id=1;
select * from tx;
+------+------+
| id   | num  |
+------+------+
|    1 |   10 |
|    2 |    2 |
|    3 |    3 |
+------+------+
commit;

#事务A：这时候即使事务B已经提交了,但A能不能看到数据变化？
select * from tx;
+------+------+
| id   | num  |
+------+------+
|    1 |    1 | --->还是看不到的！(这个级别2不一样，也说明级别3解决了不可重复读问题)
|    2 |    2 |
|    3 |    3 |
+------+------+

#事务A：只有当事务A也提交了，它才能够看到数据变化
commit;
select * from tx;
+------+------+
| id   | num  |
+------+------+
|    1 |   10 |
|    2 |    2 |
|    3 |    3 |
+------+------+

　　

4、serializable

#首先修改隔离界别
set tx_isolation=‘serializable‘;
select @@tx_isolation;
+----------------+
| @@tx_isolation |
+----------------+
| SERIALIZABLE   |
+----------------+

#事务A：开启一个新事务
start transaction;

#事务B：在A没有commit之前，这个交叉事务是不能更改数据的
start transaction;
insert tx values(‘4‘,‘4‘);
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
update tx set num=10 where id=1;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

　　

总结一下： 

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

事务的隔离级别	脏读  事务1更新了记录，但没有提交，事务2读取了更新后的行，然后事务T1回滚，现在T2读取无效。违反隔离性导致的问题，添加行锁实现	不可重复读  事务1读取记录时，事务2更新了记录并提交，事务1再次读取时可以看到事务2修改后的记录（修改批更新或者删除）需要添加行锁进行实现	幻读   事务1读取记录时事务2增加了记录并提交，事务1再次读取时可以看到事务2新增的记录。需要添加表锁进行实现。InnoDB存储引擎通过多版本并发控制(MVCC，Multiversion Concurrency Control)机制解决了该问题
Read uncommitted	√	√	√
Read committed	×	√	√
Repeatable read	×	×	√
Serializable	×	×	×

注意点：

 

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

 

（2）不同的数据库存储引擎其实并没有严格按照标准来执行，如innodb默认的repeatable read隔离级别下就可以做到避免幻读的问题（采用了Next-Key-Lock锁的算法）。InnoDB和Falcon存储引擎通过多版本并发控制(MVCC，Multiversion Concurrency Control)机制解决了该问题。

 

 

对应着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 [[email protected]] for JDBC transaction
 - Switching JDBC Connection [[email protected]] to manual commit
 - Suspending current transaction, creating new transaction with name [com.baobaotao.service.UserService.addCredits]
 - Acquired Connection [[email protected]] for JDBC transaction
 - Switching JDBC Connection [[email protected]] to manual commit
 - Initiating transaction commit
 - Committing JDBC transaction on Connection [[email protected]]
 - Releasing JDBC Connection [[email protected]] after transaction
 - Returning JDBC Connection to DataSource
 - Resuming suspended transaction after completion of inner transaction
 - Initiating transaction commit
 - Committing JDBC transaction on Connection [[email protected]]
 - Releasing JDBC Connection [[email protected]] after transaction
 - Returning JDBC Connection to DataSource

清楚的看到调用addCredis()方法时创建了一个新的事务，而在这个方法中调用addCredits()方法时，由于这个方法的事务传播行为为progation_required_new，所以挂起了当前的线程，又创建了一个新的线程。但是对于this.updateTopic()方法调用时，由于这个

方法的事务仍然为propagation_required，所以在当前线程事务中执行即可。

 

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

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

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

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

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

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