当 Redis 碰上 @Transactional，有大坑，要注意！

浅浅的花香味﹌ 2023-10-12 15:24 21阅读 0赞

最近项目的生产环境遇到一个奇怪的问题：

现象：每天早上客服人员在后台创建客服事件时，都会创建失败。当我们重启这个微服务后，后台就可以正常创建了客服事件了。到第二天早上又会创建失败，又得重启这个微服务才行。

初步排查：创建一个客服事件时，会用到 Redis 的递增操作来生成一个唯一的分布式 ID 作为事件 id。代码如下所示：

return redisTemplate.opsForValue().increment("count", 1);

而恰巧每天早上这个递增操作都会返回 `null`，进而导致后面的一系列逻辑出错，保存客服事件失败。当重启微服务后，这个递增操作又正常了。

> 那么排查的方向就是 Redis 的操作为什么会返回 null 了，以及为什么重启就又恢复正常了。

## 二、排查 ##

根据上面的信息，我们先来看看 Redis 的自增操作在什么情况下会返回 null。

### 2.1 推测一 ###

根据重启后就恢复正常，我们推测晚上执行了大量的 job，大量 Redis 连接未释放，当早上再来执行 Redis 操作时，执行失败。重启后，连接自动释放了。

但是其他有使用到 Redis 的业务功能又是正常的，所以推测一的方向有问题，排除。

### 2.2 推测二 ###

可能是 Redis 事务造成的问题。这个推测的依据是根据下面的代码来排查的。

直接看 `redisTemplate` 递增的方法 `increment`，如下所示：

![c2863efa962dad207360a640081e4931.png][]

官方注释已经说明什么情况下会返回 null：

*  当在 pipeline（管道）中使用这个 increment 方法时会返回 null。
 *  当在 transaction（事务）中使用这个 increment 方法时会返回 null。

> 事务提供了一种将多个命令打包，然后一次性、有序地执行机制.
> 
> 多个命令会被入列到事务队列中，然后按先进先出（FIFO）的顺序执行。
> 
> 事务在执行过程中不会被中断，当事务队列中的所有命令都被执行完毕之后，事务才会结束。（内容来自 Redis 设计与实现）

继续看代码，发现在操作 Redis 的 ServiceImpl 实现类的上面添加了一个 @Transactional 注解，推测是不是这个注解影响了 Redis 的操作结果。

### 2.3 验证推测二 ###

如下面的表格所示，第二行中没有添加 Spring 的事务注解`@Transactional`时，执行 Redis 的递增命令肯定是正常的，而接下来要验证的是表格中的第一行：加了 `@Transactional` 是否对 Redis 的命令有影响。

![db95b70f52809f8cddc9e4132cd6c662.png][]

为了验证上面的推论，我写了一个 Demo 程序。

Controller 类，定义了一个 API，用来模拟前端发起的请求：

![857827b7675e311aa71e0f289f673d3a.png][]

Service 实现类，定义了一个方法，用来递增 Redis 中的 count 键，每次递增 1，然后返回命令执行后的结果。而且这个 Service 方法加了@Transactional 注解。

![1552ced8e4307978cd372de165e38a67.png][]

Postman 测试下，发现每发一次请求，count 都会递增 1，并没有返回 null。

![08e3403291dbeb57c96733b07f78bde2.png][]

然后到 Redis 中查看数据，count 的值也是递增后的值 38，也不是 null。

![870a80b614b725d0137452d81ffa60bd.png][]

通过这个实验说明在 @Transactional 注解的方法里面执行 Redis 的操作并不会返回 null，结论我记录到了表格中。

![666718b19de808e30a330f67da871eba.png][]

所以说上面的推论不成立（加了 @Transactional 注解并不影响），到这里线索似乎断了。

### 2.4 推测三 ###

然后跟当时做这块功能的开发人员说明了情况，告诉他可能是 Redis 事务造成的，然后问有没有其他同学在凌晨执行过 Redis 事务相关的 Job。

他说最近有同事加过 Redis 的事务功能，在凌晨执行 Job 的时候用到事务。我将这位同事加的代码简化后如下所示：

![80c01576377d3d809e0d273a95c6e662.png][]

下面是针对这段代码的解释，简单来说就是开启事务，将 Redis 命令顺序放到一个队列中，然后最后一起执行，且保证原子性。

`setEnableTransactionSupport`表示是否开启事务支持，默认不开启。

![0b2026599b656e49b946f19c22f534cf.png][]

> 难道开启了 Redis 事务，还能影响 Spring 事务中的 Redis 操作？

### 2.5 验证推测三 ###

如下表，序号 3 和 序号 4 的场景都是**开启了 Redis 的事务支持**，两个场景的区别是**是否加了 @Transactional 注解**。

![781c4f83bdb849066a5caad5fc927a5e.png][]

为了验证上面的场景，我们来做个实验：

*  先开启 Redis 事务支持，然后执行 Redis 的事务命令 multi 和 exec 。
 *  验证场景 3：在 @Transactional 注解的方法中执行 Redis 的递增操作。
 *  验证场景 4：在非 @Transactional 注解的方法中执行 Redis 的递增操作

2.5.1 执行 Redis 事务

首先就用 Redis 的 multi 和 exec 命令来设置两个 key 的值。

![5abe2cfe8c40eb53b74408c8aeef4b53.png][]

如下图所示，设置成功了。

![f80cd0cda12433189294954532683bb5.png][]

2.5.2 @Transactional 中执行 Redis 命令

接下来在标注有 @Transactional 注解的方法中执行 Redis 的递增操作。

![7ce9dc3d2eb43acbcb28fb2956d40215.png][]

多次执行这个命令返回的结果都是 null，这不就正好重现了！

![2aa465ff55521571e975a32d6da061b8.png][]

再来看 Redis 中 count 的值，发现每执行一次 API 请求调用，都会递增 1，所以虽然命令返回的是 null，但最后 Redis 中存放的还是递增后的结果。

![3a2a0a5fa936d318338e9c289a60017e.png][]

![83f2d59cbb4bbeed39cdd23bf8e92cab.png][]

接下来我们验证下场景 4，先执行 Redis 事务操作，然后在不添加 @Transactional 注解的方法中执行 Redis 递增操作。

![7ce8d02c6dfdf06d27ede39a9f8edac4.png][]

用 Postman 调用这个接口后，正常返回自增后的结果，并不是返回 null。说明在非 @Transactional 中执行 Redis 操作并没有受到 Redis 事务的影响。

![6bd9df84f1c0082a21854788681bb861.png][]

四个场景的结论如下所示，只有第三个场景下，Redis 的递增操作才会返回 null。

![0b45ebd58d208446d04fbf1a26af618b.png][]

问题原因找到了，说明 RedisTemplete 开启了 Redis 事务支持后，在 @Transactional 中执行的 Redis 命令也会被认为是在 Redis 事务中执行的，要执行的递增命令会被放到队列中，不会立即返回执行后的结果，返回的是一个 null，需要等待事务提交时，队列中的命令才会顺序执行，最后 Redis 数据库的键值才会递增。

## 三、源码解析 ##

那我们就看下为什么开启了 Redis 事务支持，效果就不一样了。

找到 Redis 执行命令的核心方法， execute 方法。

![88a24c5fec02b1d5d36958dae5d0a67b.png][]

然后一步一步点进去看，关键代码就是 211 行到 216 行，有一个逻辑判断，当开启了 Redis 事务支持后，就会去绑定一个连接（`bindConnection`），否则就去获取新的 Redis 连接（`getConnection`）。这里我们是开启了的，所以再到 `bindConnection`方法中查看如何绑定连接的。

![f81956c2f18d3885551e353bcef20143.png][]

接着往下看，关键代码如下所示，当开启了 Redis 事务支持，且添加了 @Transactional 注解时，就会执行 Redis 的 mutil 命令。

**关键代码：conn.multi();**

![70a61b3173d64ff05b0e7caf91a813ae.png][]

Redis Multi 命令用于标记一个事务块的开始，事务块内的多条命令会按照先后顺序被放进一个队列当中，最后由 EXEC 命令原子性(atomic)地执行。

> 真相大白，开启 Redis 事务支持 + @Transactional 注解后，最后其实是标记了一个 Redis 事务块，后续的操作命令是在这个事务块中执行的。

比如下面的的递增命令并不会返回递增后的结果，而是返回 null。

stringRedisTemplate.opsForValue().increment("count", 1);

而我们的生产环境重启服务后，开启的 Redis 事务支持又被重置为默认值了，所以后续的 Redis 递增操作都能正常执行。

## 四、修复方案 ##

目前想到了两种解决方案：

*  方案一：每次 Redis 的事务操作完成后，关闭 Redis 事务支持，然后再执行 @Transactional 中的 Redis 命令。（有弊端）
 *  方案二：创建两个 StringRedisTemplate，一个专门用来执行 Redis 事务，一个用来执行普通的 Redis 命令。

### 4.1 方案一 ###

方案一的写法如下，先开启事务支持，事务执行之后，再关闭事务支持。

![eabcf68dd119d2fffb4fb161809d4601.png][]

但是这种写法有个弊端，如果在执行 Redis 事务期间，在 @Transactional 注解的方法里面执行 Redis 命令，则还是会造成返回结果为 null。

![5873c9f83793dcf5de0936329447cc4f.png][]

### 4.2 方案二 ###

弄两个 RedisTemplate Bean，一个是用来执行 Redis 事务的，一个是用来执行普通 Redis 命令的（不支持事务）。不同的地方引入不同的 Bean 就可以了。

先创建一个 RedisConfig 文件，自动装配两个 Bean。一个 Bean 名为 `stringRedisTemplate` 代表不支持事务的，执行命令后立即返回实际的执行结果。另外一个 Bean 名为 `stringRedisTemplateTransaction`，代表开启 Redis 事务支持的。

代码如下所示：

![003790bceaf322a868bfa7d0537b7884.png][]

接下来在测试的 Service 类中注入两个不同的 StringRedisTemplate 实例，代码如下所示：

![1a309153528966eadf68d596913d35b0.png][]

Redis 事务的操作改写成这样，且不需要手动开启 Redis 事务支持了。用到的 StringRedisTemplate 是支持事务的那个实例。

![be5db8740406590bf443ed7cada20c1c.png][]

在 Spring 的 @Tranactional 中执行的 Redis 命令如下所示，用到的 StringRedisTemplate 是不支持事务的那个实例。

![0a48e841f2c6e86e116e5475f2f87e56.png][]

然后还是按照上面场景 3 的测试步骤，先执行 testRedisMutil 方法，再执行 testTransactionAnnotations 方法。

**验证结果**：Redis 递增操作正常返回 count 的值，修复完成。

另外关于 Redis 事务使用还有一个坑，就是 Redis 连接未释放，导致获取不到连接了，这是下一个话题了~

[c2863efa962dad207360a640081e4931.png]: https://img-blog.csdnimg.cn/img_convert/c2863efa962dad207360a640081e4931.png
[db95b70f52809f8cddc9e4132cd6c662.png]: https://img-blog.csdnimg.cn/img_convert/db95b70f52809f8cddc9e4132cd6c662.png
[857827b7675e311aa71e0f289f673d3a.png]: https://img-blog.csdnimg.cn/img_convert/857827b7675e311aa71e0f289f673d3a.png
[1552ced8e4307978cd372de165e38a67.png]: https://img-blog.csdnimg.cn/img_convert/1552ced8e4307978cd372de165e38a67.png
[08e3403291dbeb57c96733b07f78bde2.png]: https://img-blog.csdnimg.cn/img_convert/08e3403291dbeb57c96733b07f78bde2.png
[870a80b614b725d0137452d81ffa60bd.png]: https://img-blog.csdnimg.cn/img_convert/870a80b614b725d0137452d81ffa60bd.png
[666718b19de808e30a330f67da871eba.png]: https://img-blog.csdnimg.cn/img_convert/666718b19de808e30a330f67da871eba.png
[80c01576377d3d809e0d273a95c6e662.png]: https://img-blog.csdnimg.cn/img_convert/80c01576377d3d809e0d273a95c6e662.png
[0b2026599b656e49b946f19c22f534cf.png]: https://img-blog.csdnimg.cn/img_convert/0b2026599b656e49b946f19c22f534cf.png
[781c4f83bdb849066a5caad5fc927a5e.png]: https://img-blog.csdnimg.cn/img_convert/781c4f83bdb849066a5caad5fc927a5e.png
[5abe2cfe8c40eb53b74408c8aeef4b53.png]: https://img-blog.csdnimg.cn/img_convert/5abe2cfe8c40eb53b74408c8aeef4b53.png
[f80cd0cda12433189294954532683bb5.png]: https://img-blog.csdnimg.cn/img_convert/f80cd0cda12433189294954532683bb5.png
[7ce9dc3d2eb43acbcb28fb2956d40215.png]: https://img-blog.csdnimg.cn/img_convert/7ce9dc3d2eb43acbcb28fb2956d40215.png
[2aa465ff55521571e975a32d6da061b8.png]: https://img-blog.csdnimg.cn/img_convert/2aa465ff55521571e975a32d6da061b8.png
[3a2a0a5fa936d318338e9c289a60017e.png]: https://img-blog.csdnimg.cn/img_convert/3a2a0a5fa936d318338e9c289a60017e.png
[83f2d59cbb4bbeed39cdd23bf8e92cab.png]: https://img-blog.csdnimg.cn/img_convert/83f2d59cbb4bbeed39cdd23bf8e92cab.png
[7ce8d02c6dfdf06d27ede39a9f8edac4.png]: https://img-blog.csdnimg.cn/img_convert/7ce8d02c6dfdf06d27ede39a9f8edac4.png
[6bd9df84f1c0082a21854788681bb861.png]: https://img-blog.csdnimg.cn/img_convert/6bd9df84f1c0082a21854788681bb861.png
[0b45ebd58d208446d04fbf1a26af618b.png]: https://img-blog.csdnimg.cn/img_convert/0b45ebd58d208446d04fbf1a26af618b.png
[88a24c5fec02b1d5d36958dae5d0a67b.png]: https://img-blog.csdnimg.cn/img_convert/88a24c5fec02b1d5d36958dae5d0a67b.png
[f81956c2f18d3885551e353bcef20143.png]: https://img-blog.csdnimg.cn/img_convert/f81956c2f18d3885551e353bcef20143.png
[70a61b3173d64ff05b0e7caf91a813ae.png]: https://img-blog.csdnimg.cn/img_convert/70a61b3173d64ff05b0e7caf91a813ae.png
[eabcf68dd119d2fffb4fb161809d4601.png]: https://img-blog.csdnimg.cn/img_convert/eabcf68dd119d2fffb4fb161809d4601.png
[5873c9f83793dcf5de0936329447cc4f.png]: https://img-blog.csdnimg.cn/img_convert/5873c9f83793dcf5de0936329447cc4f.png
[003790bceaf322a868bfa7d0537b7884.png]: https://img-blog.csdnimg.cn/img_convert/003790bceaf322a868bfa7d0537b7884.png
[1a309153528966eadf68d596913d35b0.png]: https://img-blog.csdnimg.cn/img_convert/1a309153528966eadf68d596913d35b0.png
[be5db8740406590bf443ed7cada20c1c.png]: https://img-blog.csdnimg.cn/img_convert/be5db8740406590bf443ed7cada20c1c.png
[0a48e841f2c6e86e116e5475f2f87e56.png]: https://img-blog.csdnimg.cn/img_convert/0a48e841f2c6e86e116e5475f2f87e56.png