一次 Redis 事务使用不当引发的生产事故-低调大师

一次 Redis 事务使用不当引发的生产事故

2022-10-25 368

这是悟空的第 170 篇原创文章

官网：www.passjava.cn

你好，我是悟空。

本文主要内容如下：

一、前言

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

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

初步排查：创建一个客服事件时，会用到 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，如下所示：

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

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

事务提供了一种将多个命令打包，然后一次性、有序地执行机制.

多个命令会被入列到事务队列中，然后按先进先出（FIFO）的顺序执行。

事务在执行过程中不会被中断，当事务队列中的所有命令都被执行完毕之后，事务才会结束。（内容来自 Redis 设计与实现）

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

2.3 验证推测二

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

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

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

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

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

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

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

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

2.4 推测三

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

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

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

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

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

2.5 验证推测三

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

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

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

2.5.1 执行 Redis 事务

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

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

2.5.2 @Transactional 中执行 Redis 命令

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

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

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

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

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

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

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

三、源码解析

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

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

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

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

关键代码：conn.multi();

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

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

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

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

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

四、修复方案

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

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

4.1 方案一

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

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

4.2 方案二

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

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

代码如下所示：

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

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

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

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

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

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

参考资料：https://blog.csdn.net/qq_34021712/article/details/79606551

- END -

关于我

8 年互联网开发经验，擅长微服务、分布式、架构设计。目前在一家大型上市公司从事基础架构和性能优化工作。

InfoQ 签约作者、蓝桥签约作者、阿里云专家博主、51CTO 红人。

微信关注我们

原文链接：https://my.oschina.net/u/4499317/blog/5586131

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

统信首届技术开放日，硬核技术引领操作系统“大迁移”

10月24日程序员节之际，统信软件首届技术开放日在国家信创园区圆满落下帷幕。统信软件首届技术开放日囊括UP主直播互动、打卡探园、“大迁移”主题论坛、全系产品体验等精彩环节。来自统信软件研发部门负责人、行业专家、技术大咖以及专业媒体代表百余人莅临活动现场，共话国产操作系统迁移落地进展与未来。统信技术开放日是统信软件打造的一个面向开发者、合作伙伴和用户朋友的实用性和知识性活动平台，致力于赋能开发者与合作伙伴解决数字化转型中的技术所需、提升数字化转型效能、获取丰富的技术热点与创新趋势。本期技术开放日主题为“大迁移”，统信软件聚焦用户在系统迁移、信创升级中遇到的实际问题。下面就让我们一起来感受本期技术开放日精彩的看点内容吧！打卡探园·探寻统信18年成长之旅一年一度的1024程序员节，自然不能少了大家喜闻乐见的栏目：UP主直播探园+答题打卡赢礼品+体验新产品，一步步探寻和感受统信软件18年的发展与成长之旅。从诞生至今，18年18个瞬间，更像是一个人的成长，从出生到壮大，现在正是统信软件最好的年华。 18年的初心坚持，统信因理想而出生，为责任而成长。数字时代，统信软件站在数字经济蓬勃发展的...

2022-10-25

332

GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。 GreatSQL是MySQL的国产分支版本，使用上与MySQL一致。前情提要当前读快照读什么是MVCC 三个隐藏字段 Undo Log回滚日志 MVCC版本链 ReadView读视图不同隔离级别下MVCC分析 READ-COMMITTED隔离级别 REPEATABLE-READ隔离级别前情提要事务有四大特性ACID分别是：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）其中隔离性是通过数据库的锁加上MVCC(多版本并发控制)来保证的。在介绍MVCC之前先来了解一下当前读和快照读。当前读当前读读取的是记录的最新版本。同时在读取的时候还要保证其他的并发事务不能更改当前记录，那么当前读会对它要读取的记录进行加锁。不同的操作会加上不同类型的锁，如：SELECT ... LOCK IN SHARE MODE(共享锁)，SELECT ... FOR UPDATE、UPDATE、INSERT、 DELETE(排他锁)。快照读...

2022-10-25

369

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。