五分钟读完权威书籍的Redis事务_学习总结
Posted 如月之恒-
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了五分钟读完权威书籍的Redis事务_学习总结相关的知识,希望对你有一定的参考价值。
前言
Redis在项目实际开发中,经常会使用到的中间件。作为缓存数据的工具,就必然会有保证数据原子性的问题,那么我们今天就来谈谈Redis的事务吧。
文章主体脉络:
Redis事务要解决的问题?→Redis事务的简单使用→使用会引发的问题→如何解决这个问题:watch→watch的实现机制→事务会引发的问题。
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的事务的使用过程,大家对事务的使用基本有了了解,但事务执行可能存在一个问题。
问题场景:
- A客户端(应用程序)获取了num1=1、num2=10的值,A要对num1+1,然后num2+num1。理论上,我们开启事务,set num1 2 set num2 = 12。
- B客户端在随后也做了A客户端的一样的操作,理论上我们最终结果应该是num1=3,num2=15。
- 现在问题来了,假设B与A是同时进行了这个操作,我们最后的结果变成num=2,num2=12了。
- 这就违背了我们初衷,这在计算的时候经常遇见。
- 那我们怎么去确保最终结果符合预期呢?办法就是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命令,要考虑应用程序出错的时候加回去】
后言(必读)
- 题目是五分钟读完,不是五分钟学会。
- 笔者希望各位读者(无论自认为是大佬或小白)能够对文章提出问题或指出错误,笔者一定会跟进进行问题的解答,错误之处笔者会继续学习,完善本文内容。望各位不吝赐教。
- 如果没有自己问题和建议,对你来说只有输入知识,没有输出,学习效果并不好。
- 如果你觉得评论沟通不方便,想问的问题/笔者的观点错误过多,愿意向笔者询问和指正的话,也可以添加笔者微信(o815441)进行探讨,笔者乐意之至。请备注“探讨技术问题”。
参考资料
- 《Redis的设计与实现》——黄健宏
以上是关于五分钟读完权威书籍的Redis事务_学习总结的主要内容,如果未能解决你的问题,请参考以下文章