五分钟读完权威书籍的Redis事务

·  阅读 1058

前言

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根据状态值来判断这个事务是否可以执行。

图:watched_keys数据结构说明

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

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

事务引发的问题

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

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

参考资料

  • 《Redis的设计与实现》——黄健宏
分类:
阅读
标签:
分类:
阅读
标签:
收藏成功!
已添加到「」, 点击更改