前言

Redis在项目实际开发中，经常会使用到的中间件。作为缓存数据的工具，就必然会有保证数据原子性的问题，那么我们今天就来谈谈Redis的事务吧。

文章主体脉络： Redis事务要解决的问题？→Redis事务的简单使用→使用会引发的问题→如何解决这个问题：watch→watch的实现机制→事务会引发的问题。

注意事项（必读）

• 题目是五分钟读完，不是五分钟学会。
• 笔者希望各位读者（无论自认为是大佬或小白）能够对文章提出问题或指出错误，笔者一定会跟进进行问题的解答，错误之处笔者会继续学习，完善本文内容。望各位不吝赐教。
• 如果没有自己问题和建议，那么我建议你不要看这篇文章，对你来说只有输入知识，没有输出，没有任何的学习效果，所以你就不要浪费时间了，去刷个抖音都比假装自己很努力来得强。
• 如果你觉得评论沟通不方便，想问的问题/笔者的观点错误过多，愿意向笔者询问和指正的话，也可以添加笔者微信（o815441）进行探讨，笔者乐意之至。请备注“探讨技术问题”。

Redis为了解决什么问题？

---

在MySQL和Spring都有进行事务控制的方法。Redis作为缓存，我们操作Redis的数据时在特定场景下也要保证我们操作的命令的ACID属性。那么Redis有提供这样的办法吗？有的。那我们今天就来聊下Redis的事务。

为什么需要Redis事务（问题场景）？

---

一定要理解Redis的事务要解决什么问题，才能有全局意识，他所有的做法都是为了解决这个问题。

业务系统需要在Redis中设置值，并最终获取数据：

//示例代码
set name "zhangsan";
set age 25;
get name;--希望获取到"张三"

按照示例代码，通常我们会发送三个命令给Redis进行数据设置和获取，一般情况下我们可以获取到name=“张三”。

那么请你思考下，这样的请求会不会有问题呢？

恭喜你答对了。会的。我们发现如果在我们命令执行中间，有一个客户B对执行了set “name” "李四"命令。那我们获取到的name值就是“李四”了，与我们预期获取的值不同。

我的天啊，那怎么办？很简单，就是利用Redis的事务进行控制，我们就可以保证获取到name="张三"。那么Redis的事务应该怎么使用呢？

如何使用Redis的事务机制？

Redis的事务执行分为三个阶段：事务开启、命令入队，事务执行。

先给出一个Redis事务的完整命令：

1、事务开启

命令MULTI

表示该客户端进入事务状态，后续编辑的命令，除了watch、exce、discard、multi等四个命令外，其他命令都会先入队列，等到我们使用EXEC命令后再一并执行。

这里就引出了客户端的事务状态和非事务状态。

客户端运行MULTI命令后，会打开事务状态，会在客户端状态的flags属性中打开Redis_Multi表示来完成。

2、命令入队

事务状态和非事务状态执行命令的逻辑不同。

3、事务执行

命令EXEC

客户端执行exec命令后，redis就会执行我们事务中的整个队列的命令。中途不会有其他事务可以操作redis（redis单线程）。

但有一点要注意：Redis没有像MySQL那样的回滚机制的，根据作者的说法，意思就是按照Redis设计，如果执行的命令有问题，就是客户端的问题。其次，作为轻量级应用，不应该加回滚操作。总而言之，你的愚蠢不要怪Redis。

讲完了Redis的事务的使用过程，大家对事务的使用基本有了了解，但事务执行可能存在一个问题。

问题场景：

1. A客户端（应用程序）获取了num1=1、num2=10的值，A要对num1+1，然后num2+num1。理论上，我们开启事务，set num1 2 set num2 = 12。
2. B客户端在随后也做了A客户端的一样的操作，理论上我们最终结果应该是num1=3,num2=15。
3. 现在问题来了，假设B与A是同时进行了这个操作，我们最后的结果变成num=2,num2=12了。
4. 这就违背了我们初衷，这在计算的时候经常遇见。
5. 那我们怎么去确保最终结果符合预期呢？办法就是WATCH命令。

Watch命令的实现原理

WATCH命令本质上是乐观锁,原理跟CAS类似，就是监控键值对，如果在监控后键值对被其他客户端改变，那么我们接下去要执行的事务就会被拒绝。这点我觉得跟CAS的设计思路有类似的地方。CAS是在更新时比较旧值是否相等，Redis时通过维护一个Watched_keys字典的状态来确定旧值是否已更改。 所以： 比如num1=3，A watch的时候num1=3,B set num1 3。这种情况下，CAS是允许修改数据的，但Redis不允许的。如下图所示：

那Watch的实现原理是怎样的呢？

Redis提供了一张WATCH_KEY数据结构，监控的num1为key，监控这个键值的客户端是一个链表。当num1的值被修改了，那么监控这个num1的客户端的状态REDIS_DIRTY_CAS就会被打开，在事务执行的时候，redis根据状态值来判断这个事务是否可以执行。

这就是Watch的大致实现原理了。

大致讲完Redis的事务，读者可以想下，Redis事务可能引发什么问题呢？

事务引发的问题

笔者认为最明显的问题就是阻塞其他客户端的访问。如果执行一个长命令，比如keys 获取十万个key值，这就很麻烦了，如果事务里有两个是执行keys 获取十万条key值呢。当然这样的操作有违Redis的设计初衷。（你蠢不能怪Redis），深入了解一个工具是为了更好的使用他。

笔者认为Redis的事务可以当成是业务代码实现并发控制的一种简单方式手段。比如秒杀系统的库存经常会存到Redis，通常我们都要避免超卖，库存为0就返回给客户端没有了。在这种情况下就可以使用Redis的事务。不然A客户端原本获取到的库存repertoryCount=1，结果在他运行的时候，其他客户端也在下单。这就造成了超卖。【秒杀这个应用场景待商榷，希望各位提建议，笔者自己想出来的就是这个很蠢的假设场景，实际业务中我们直接用DECR key减一更香，如果直接使用DECR命令，要考虑应用程序出错的时候加回去】

参考资料

• 《Redis的设计与实现》——黄健宏