SpringBoot--解决@Transactional与@CacheEvict联合使用导致的缓存与数据库的一致性问题

矫情吗；* 2023-09-29 17:08 0阅读 0赞

原文网址：[SpringBoot--解决@Transactional与@CacheEvict联合使用导致的缓存与数据库的一致性问题\_IT利刃出鞘的博客-CSDN博客][SpringBoot--_Transactional_CacheEvict_IT_-CSDN]

## 简介 ##

**说明**

本文介绍@Transactional与@CacheEvict联合使用导致的缓存与数据库的一致性问题的原因及解决方案。

**注解的作用**

@Transactional：给方法添加事务支持，方法执行完之后提交事务。（通过 AOP 动态代理实现的）。

@CacheEvict：在该方法执行完之后，清除 redis 中的缓存，也是使用 AOP 动态代理实现的。

> **粉丝福利**：有很多粉丝私信问我有没有Java的面试及PDF书籍等资料，我整理一下，包含：**真实**面试题汇总、简历模板、PDF书籍、PPT模板等。这些是**我自己也在用**的资料，面试题是面试官问到我的问题的整理，其他资料也是我自用的，真正**实用、靠谱**。资料可以从这里免费获取：[资料地址][Link 1]

## 问题引出 ##

如果是@Transactional与@CacheEvict用在同一个方法上边，是否有问题？

是否可以达到如下效果：先保存到数据库，提交数据库事务，然后清除缓存？

![28d66941bce346a29ff2b8c6b86b113b.png][]

## 打断点分析 ##

### 给@CacheEvict打断点 ###

执行清除缓存的是org.springframework.cache.Cache\#evict方法，此处是使用 redis 作为缓存的提供者，所以在清除缓存时必然会调用 redis 缓存实现类的方法，即：org.springframework.data.redis.cache.RedisCache\#evict。于是，在该方法处加一个断点：

![fb660c79d5a04dec852fbece3999ed4e.png][]

### 给@Transactional打断点 ###

对于 JDBC 事务而言，想要提交事务就要调用java.sql.Connection\#commit方法。由于笔者此处使用的是 MySQL 数据库，所以这里对应的实现类为com.mysql.jdbc.ConnectionImpl\#commit。于是，同样在该方法加一个断点：

![bf31f42a11dd494d8e7c897421961df2.png][]

### 测试程序 ###

在执行 save 方法之前，通过调用 getById 方法已经将对应的数据缓存到了 redis 中。此时，Redis和数据库中 countNumber 的值为 1。

![8f52cb53b27d4f3997cae0ada3ef5be1.png][]

### 测试 ###

调用save方法，id为1，countNumber为2。

1.  首先命中了org.springframework.data.redis.cache.RedisCache\#evict方法的断点，执行完该方法之后，对应的Redis数据已被清除（countNumber为空）。此时数据库里countNumber仍然是1。
2.  再向下运行，到达com.mysql.jdbc.ConnectionImpl\#commit，执行事务提交，执行完后，数据库里countNumber变成2

我们希望先提交事务，然后更新缓存。而真正的执行顺序是，先清除缓存，然后提交事务。

**这样存在的问题：数据库和缓存数据不一致**

先清除缓存，然后在事务还没有提交之前，程序就收到了用户的请求，发现缓存中没有数据，则去数据库中获取数据（事务还没有提交则获取到旧值），同时将获取的数据添加到缓存中。此时会导致数据库和缓存数据不一致。

## 解决方案 ##

### 方案1：将事务单独拿出为一个方法 ###

![ec044b674ba74690b5c422f707afe3c4.png][]

### 方案2：修改AOP执行顺序 ###

修改 AOP 的执行顺序：改成先提交事务，再清除缓存。

方法如下：

@EnableCaching(order = Ordered.HIGHEST_PRECEDENCE)

**注意**

优先级越高不是应该越先执行吗？缓存 AOP 的优先级最高怎么比事务提交 AOP 执行的要晚呢？

多个 advice 运行在同一个 join point 时,Spring AOP 遵循与 AspectJ 相同的优先级规则来确定建议执行的顺序。可以通过实现org.springframework.core.Ordered接口或者使用@Order注解来控制其执行顺序。优先级最高的 advice 首先“在入口”运行，从 join point“出来”时，优先级最高的 advice 将最后运行。

可以把 Spring AOP 想象成一个同心圆。被增强的原始方法在圆心，每一层 AOP 就是增加一个新的同心圆。同时，优先级最高的在最外层。方法被调用时，从最外层按照 AOP1、AOP2 的顺序依次执行 around、before 方法，然后执行 method 方法，最后按照 AOP2、AOP1 的顺序依次执行 after 方法。

![bf616a8783f4439ca616809cfa10649c.png][]

## 修改AOP顺序的方法分析 ##

### 断点入口 ###

![f315df6bec634200bf92778321bdc225.png][]

@Transactional和@CacheEvict都是通过动态代理来实现的，在执行 save 方法处打一个断点，命中断点之后，点击Step Into，就可以进入到代理对象的执行方法内。

### 拦截的方法 ###

![4e2a919938104695b9bf81cb3feb2d52.png][]

可以看到，执行 save 方法之前，被CglibAopProxy.DynamicAdvisedInterceptor\#intercept方法所拦截了。（在 SpringBoot2.0 之后，SpringBoot 中 AOP 的默认实现被设置成了默认使用 CGLIB 来实现了。）

### 所有的切面 ###

![8a82e0902417445a98c50caff985f30b.png][]

通过 debug 可以发现：advised.advisors是一个 List，List 中的两个 Advisor 分别为：

*  org.springframework.cache.interceptor.BeanFactoryCacheOperationSourceAdvisor: advice org.springframework.cache.interceptor.CacheInterceptor@4b2e3e8f
 *  org.springframework.transaction.interceptor.BeanFactoryTransactionAttributeSourceAdvisor: advice org.springframework.transaction.interceptor.TransactionInterceptor@27a97e08

**那怎么修改 List 内元素的顺序呢？**

通过查看BeanFactoryCacheOperationSourceAdvisor和BeanFactoryTransactionAttributeSourceAdvisor的源码可知，这两个类均继承了org.springframework.aop.support.AbstractPointcutAdvisor，而AbstractPointcutAdvisor这个抽象类实现了org.springframework.core.Ordered接口。

猜想：那我们是不是可以通过修改 getOrder()方法的返回值来影响 List 中的排序呢？

### Order的设置方法 ###

![640cfe34d30c473b8a4bc00c06233b7e.png][]

![28dd625df4ad4d6fa98b463ba79398a4.png][]

以BeanFactoryTransactionAttributeSourceAdvisor为例，order 的值来自于AnnotationAttributes enableTx对象的某个属性。

![c92355c3bf014b3981509fdf4eb18b44.png][]

通过源码可以发现，AnnotationAttributes enableTx的属性全部都来自于@EnableTransactionManagement注解。

![eb8d43da96774617b12308482ae2ce07.png][]

同理，@EnableCaching注解上也可以配置 order，这里不在赘述。

## 其他网址 ##

[当@Transactional遇到@CacheEvict，你的代码是不是有bug！ - 腾讯云开发者社区-腾讯云][Transactional_CacheEvict_bug_ - _-]

[SpringBoot--_Transactional_CacheEvict_IT_-CSDN]: https://knife.blog.csdn.net/article/details/126655196
[Link 1]: https://app.yinxiang.com/fx/d2ac6ff4-94c5-4e5f-9d4f-f5dfc344ede6
[28d66941bce346a29ff2b8c6b86b113b.png]: https://img-blog.csdnimg.cn/28d66941bce346a29ff2b8c6b86b113b.png
[fb660c79d5a04dec852fbece3999ed4e.png]: https://img-blog.csdnimg.cn/fb660c79d5a04dec852fbece3999ed4e.png
[bf31f42a11dd494d8e7c897421961df2.png]: https://img-blog.csdnimg.cn/bf31f42a11dd494d8e7c897421961df2.png
[8f52cb53b27d4f3997cae0ada3ef5be1.png]: https://img-blog.csdnimg.cn/8f52cb53b27d4f3997cae0ada3ef5be1.png
[ec044b674ba74690b5c422f707afe3c4.png]: https://img-blog.csdnimg.cn/ec044b674ba74690b5c422f707afe3c4.png
[bf616a8783f4439ca616809cfa10649c.png]: https://img-blog.csdnimg.cn/bf616a8783f4439ca616809cfa10649c.png
[f315df6bec634200bf92778321bdc225.png]: https://img-blog.csdnimg.cn/f315df6bec634200bf92778321bdc225.png
[4e2a919938104695b9bf81cb3feb2d52.png]: https://img-blog.csdnimg.cn/4e2a919938104695b9bf81cb3feb2d52.png
[8a82e0902417445a98c50caff985f30b.png]: https://img-blog.csdnimg.cn/8a82e0902417445a98c50caff985f30b.png
[640cfe34d30c473b8a4bc00c06233b7e.png]: https://img-blog.csdnimg.cn/640cfe34d30c473b8a4bc00c06233b7e.png
[28dd625df4ad4d6fa98b463ba79398a4.png]: https://img-blog.csdnimg.cn/28dd625df4ad4d6fa98b463ba79398a4.png
[c92355c3bf014b3981509fdf4eb18b44.png]: https://img-blog.csdnimg.cn/c92355c3bf014b3981509fdf4eb18b44.png
[eb8d43da96774617b12308482ae2ce07.png]: https://img-blog.csdnimg.cn/eb8d43da96774617b12308482ae2ce07.png
[Transactional_CacheEvict_bug_ - _-]: https://cloud.tencent.com/developer/article/1551858