- 事务的基本特征
- 隔离级别
- 传播行为
- @Transcation
事务的基本特征(ACID)
Atomic(原子性)
事务中包含的操作被看作一个整体的业务单元,这个业务单元中的操作要么全部成功,要么全部失败,不会出现部分失败和部分成功的场景
Consistency(一致性)
事务在完成时,必须使所有的数据都保持一直状态,在数据库中所有的修改都基于事务,保证了数据的完整性
Isolation(隔离性)
多个应用程序线程同时访问统一数据,这样数据库同样的数据就会在各个不同的事务中被访问,这样会产生丢失更新,为了压制丢失更新的产生,数据库定义了隔离级别的概念,通过它的选择,可以在不同程度上压制丢失更新的产生。因为互联网的应用常常面对高并发的场景,所以隔离性是需要掌握的重点内容
Durability(持久性)
事务结束后,所有的数据都会固化到一个地方,如保存磁盘当中,即时断电重启后也可以提供应用程序访问
为了压制丢失更新,数据库提出了隔离级别,在不同程度上压制更新
也许会有一个疑问,都全部消除丢失更新不就好了吗,为什么只是在不同的程度.上压制丢失更新呢?
其实这个问题是从两个角度去看的,一个是数据的一致性,另一个是性能。数据库现有的技术完全可以避免丢失更新,但是这样做的代价,就是付出锁的代价,在互联网中,系统不单单要考虑数据的-致性,还要考虑系统的性能。试想,在互联网中使用过多的锁,--旦出现商品抢购这样的场景,必然会导致大量的线程被挂起和恢复,因为使用了锁之后,一个时刻只能有一个线程访问数据,这样整个系统就会十分缓慢,当系统被数千甚至数万用户同时访问时,过多的锁就会引发宕机,大部分用户线程被挂起,等待持有锁事务的完成,这样用户体验就会十分糟糕。因为用户等待的时间会十分漫长,一般而言,互联网系统响应超过5秒,就会让用户觉得很不友好,进而引发用户忠诚度下降的问题。所以选择隔离级别的时候,既需要考虑数据的一致性避免脏数据,又要考虑系统性能的问题。因此数据库的规范就提出了4种隔离级别来在不同的程度上压制丢失更新。
隔离级别
未提交读
最低的隔离级别,含义是允许一个事务读取另外一个事务没有提交的数据。未提交读是一种危险的隔离级别,实际开发中应用不广
- 优点:并发能力高。适合那些对数据一致性没有要求而追求高并发的场景
- 缺点:出现脏读
读写提交
指一个事务只能读取一个事务已经提交的数据,不能读取未提交的数据
- 优点:克服脏读
- 缺点:出现不可重复读
可重复读
可重复读的目标是克服读写提交中出现的不可重复读的现象,因为在读写提交的时候,可能出现一些值的变化,影响当前事务的执行
- 优点:克服不可重复读
- 缺点:出现幻读
串行化
数据库最高的隔离级别,它会要求所有的SQL都会按照顺序执行,这样就可以克服上诉隔离级别出现的各种问题,所以它能完全保证数据的一致性
追求更高的隔离级别,它能更好地保证数据的一致性,但是也要付出锁的代价。有了锁,就意味着性能的丢失,而且隔离级别越高,性能越是直线下降。
所以在选择隔离级别时,要考虑的不单单是数据一致性问题,还要考虑系统的性能问题
一般而言,选择隔离级别会以读写提交为主,它能防止脏读,而不能避免不可重复读和幻读,为了克服数据不一致性和性能问题,程序开发者还设计了乐观锁,甚至不再使用数据库而使用其他手段
对于隔离级别,不同的数据库支持也是不一样的
- Oracle只支持读写提交和串行化,默认隔离级别为读写提交
- MySQL能支持4种,默认隔离级别为可重复读
传播行为
在Spring中,当一个方法调用另外一个方法,可以让事务采取不同的策略工作,如新建事务或挂起当前事务
在一个批量任务执行的过程中,调用多个交易时,如果有一些交易发生异常,只是回滚出现异常的交易,而不是里整个批量任务,这样就能够是的那些没有问题的交易可以吮吸完成,而有问题的交易则不做任何事情
@Transcation
对于声明式事务,使用@Transaction进行标注,可标注在类活着方法上,当它标注在类上时,代表这个类所有公共(public)非静态的方法都将启用事务功能
默认配置下 Spring 只会回滚运行时、未检查异常(继承自 RuntimeException 的异常)或者 Error。
- 捕获RuntimeException
- 捕获Error
- 并不捕获Checked Exception
有了@Transcation,Spring就会知道从哪启动事务,约定流程:
当上下文开始调用被@Transcation标注的类或者方法时,Spring就会产生AOP的功能。请注意事务的底层需要启动AOP功能,这就是Spring事务的底层实现
如有一个保存用户的方法,加入 @Transactional 注解,使用默认配置,抛出异常之后,事务会自动回滚,数据不会插入到数据库。
@RestController public class HouseController {@Autowiredprivate HouseRepository houseRepository;@GetMapping("/test1")public String test1(){houseRepository.save(new House("house1", "100平方米"));houseRepository.save(new House("house2", "100平方米"));houseRepository.save(new House("house3", "100平方米"));houseRepository.save(new House("house444444444", "100平方米"));houseRepository.save(new House("house5", "100平方米"));return "success";}@GetMapping("/test2")@Transactionalpublic String test2(){houseRepository.save(new House("house6", "100平方米"));houseRepository.save(new House("house7", "100平方米"));houseRepository.save(new House("house8", "100平方米"));houseRepository.save(new House("house999999999", "100平方米"));houseRepository.save(new House("house10", "100平方米"));return "success";} }
test1方法没有加入事务,test2方法加入了事务注解。
test1:当输入http://localhost:8888/test1
数据库中插入了三条数据
因为第四条数据太长,所以插入失败,导致第五条正常数据插入失败,这并不是我们想要的,要么全成功,要么全失败
test2:输入http://localhost:8888/test2
数据库中数据不变依然是三条数据,插入失败,所以全部回滚
本文借鉴:《深入浅出Spring Boot 2.x》书中有更详细的例子
返回顶部