跟我一起学Redis之Redis事务简单了解一下

前言

关系数据库中的事务,小伙伴们应该是不陌生了,不管是在开发还是在面试过程中,总有两个问题逃不掉:

  • 说说事务的特性;
  • 事务隔离级别是怎么一回事?

事务处理不好,数据就可能不准确,最终就会导致业务出问题;借此机会简单回顾一下事务特性及其隔离级别,就当是复习了;

事务特性(ACID)

  • 原子性(Atomicity)

    指事务内所有操作要么一起执行成功,要么都一起失败(或者说是回滚);如事务经典转账案例:A给B转账,A把钱扣了,但B没有收到;可见这种错误是不能接受的,最终会回滚,这也是原子性的重要性。

  • 一致性(Consistency)

    指事务执行前后的状态一致,如事务经典转账案例:A给B互相转账,不管怎么转,最终两者钱的总和还是不变;

  • 持久性(Durability)

    指事务一旦提交,数据就已经永久保存了,不能再回滚;

  • 隔离性(Isolation)

    指多个并发事务之间的操作互不干扰,但是事务的并发可能会导致数据脏读、不可重复读、幻读问题,根据业务情况,采用事务隔离级别进行对应数据读问题处理。

事务隔离级别

  • 读未提交(Read uncommitted)

    指一个事务读取到其他未提交事务的数据。可能导致数据脏读

    转账案例:A正在给B转账,本来转的1000,A多输入了个0,变成10000,但此事务还未提交,但此时B查询到转入的是10000,但A取消事务回滚之后,B又查询不到转入的数据。这种情况就是脏读

  • 读已提交(Read committed)

    指一个事务只能读取到其他事务已提交的数据,从而解决了脏读的问题。但可能导致数据不可重复读

    转账案例:A要给B转账1000,A先查看了一下余额,有1000,然后开始给B转钱,但此时A家里电费通过开启的自动缴费功能,自动从A账户扣除200缴纳电费,并提交;当A转账准备提交,再次确认余额时,钱少了200。这样就导致同一个事务中多次查询的结果不一致,这种情况就是不可重复读

  • 可重复读(Repeatable read)

    指事务只要一开启,就不允许其他事务进行修改操作,从而解决了不可重复读问题。但可能导致数据幻读

    转账案例:A经常给B转账,到年底了,需要查账,然后开启了一个事务进行查询统计,刚开始查询只是10条转账记录,正准备统计时,因为紧急情况A需要给B转一笔钱应急,从而新增了一条新记录,并提交;而查账事务正在统计中,最后发现转账额和看到的10条转账记录不匹配。这种情况就是幻读

  • 序列化(Serializable )

    指事务之间只能串行话执行,就像队列一样,排队进行,这样就解决了幻读的问题,但是这种级别的并发性能不高,非特殊需求,这种级别一般不用。

正文

转入正题,结合关系型数据库的事务来看看Redis中事务有什么不同;

Redis事务是指将多条命令加入队列,一次批量执行多条命令,每条命令会按顺序执行,事务执行过程中不会受客户端传入的命令请求影响。

Redis事务的相关命令如下:

  • MULTI:标识一个事务的开启,即开启事务;
  • EXEC:执行事务中的所有命令,即提交;
  • DISCARD:放弃事务;和回滚不一样,Redis事务不支持回滚。
  • WATCH:监视Key改变,用于实现乐观锁。如果监视的Key的值改变,事务最终会执行失败。
  • UNWATCH:放弃监视。

Redis事务和关系型数据库的事务不太一样,它不保证原子性,也没有隔离级别的概念。来,结合命令演示,实战说明一切:

没有隔离级别

image-20201112153132140

如上图所示,当事务开启时,事务期间的命令并没有执行,而是加入队列,只有执行EXEC命令时,事务中的命令才会按照顺序一一执行,从而事务间就不会导致数据脏读、不可重复读、幻读的问题,因此就没有隔离级别

不保证原子性

image-20201112154524168

如上图所示,在通过EXEC执行事务时,其中命令执行失败不会影响到其他命令的执行,并没有保证同时成功和同时失败的原子操作,尽管这样,Redis事务中也没有提供回滚的支持,官方提供了两个理由:

image-20201112160255544

大概的意思就是:

  • 使用Redis命令语法错误,或是将命令运用在错误的数据类型键上(如对字符串进行加减乘除等),从而导致业务数据有问题,这种情况认为是编程导致的错误,应该在开发过程中解决,避免在生产环境中发生;
  • 由于不用支持回滚功能,Redis内部简单化,而且还比较快;

在事务命令入队过程中,发现相关命令逻辑使用错误,可以进行放弃该事务;如果使用错误的Redis命令,且没有放弃事务,最终也会导致事务整体执行失败,这也算是为原子性扳回一局,如下:

放弃事务

image-20201112223050653

命令语法错误导致事务执行失败

image-20201112223821761

使用WATCH实现乐观锁

说到乐观锁,就和悲观锁一起简单说说对其的理解:

乐观锁:就是非常乐观,做什么事都往好处想; 对于数据库操作,就认为每次操作数据的时候都认为别的操作不会修改,所以不会加锁,而是通过一个类似于版本的字段来标识该数据是否修改过,在执行本次操作前先判断是否修改过,如果修改过就放弃本次操作重新再来;

悲观锁:就是非常悲观,做什么事都觉得不好;对于数据库操作,每次操作数据数据都会认为别的操作会修改当前数据,说以都要对其进行加锁,类似于表锁和行锁。

WATCH通过监视指定Redis Key,如果没有改变,就执行成功,如果发现对应值发生改变,事务就会执行失败,如下图;

image-20201112232612965

那会一直监视指定的Key吗?,答案当然是不会的,以下三种方式可以取消监视:

  • 事务执行之后,不管是否执行成功还好是失败,都会取消对应的监视;
  • 当监视的客户端断开连接时,也会取消监视;
  • 可以手动UNWATCH取消所有Key的监视;

Redis事务优缺点

优点

  • 一次性按顺序执行多个Redis命令,不受其他客户端命令请求影响;
  • 事务中的命令要么都执行(命令间执行失败互相不影响),要么都不执行(比如中间有命令语法错误);

缺点

  • 事务执行时,不能保证原子性;
  • 命令入队每次都需要和服务器进行交互,增加带宽;

注意

  • 当事务中命令语法使用错误时,最终会导致事务执行不成功,即事务内所有命令都不执行;
  • 当事务中命令知识逻辑错误,就比如给字符串做加减乘除操作时,只能在执行过程中发现错误,这种事务执行中失败的命令不影响其他命令的执行。

总结

对于Redis事务,其实用的不是很多,大部分喜欢使用Lua脚本进行批量命令的执行,同时还能保证命令执行的原子性。

那为什么要说Redis事务呢?

在之前计划写这篇文章的时候,和一些朋友简单沟通过,大家的确用的不多,基本上都是用Lua脚本;但面试会时不时遇到过Redis事务的问题,最常见的是Redis中的事务和关系型数据库中的事务有什么区别,这是从面试角度出发有这篇文章;

其实Redis 2.6版本之前,还不支持Lua脚本时,Redis事务对于批量按序执行命令的场景也是很用的;就拿当下来说,如果一些业务需批量按序执行命令的,同样可以使用,并非一定要Lua脚本。这是从使用角度来说;

最后从学习角度来说,既然学Redis,就应该尽可能的了解的多一点。 下一篇说说持久化。

一个被程序搞丑的帅小伙,关注"Code综艺圈",跟我一起学~~~

相关文章

文章浏览阅读1.3k次。在 Redis 中,键(Keys)是非常重要的概...
文章浏览阅读3.3k次,点赞44次,收藏88次。本篇是对单节点的...
文章浏览阅读8.4k次,点赞8次,收藏18次。Spring Boot 整合R...
文章浏览阅读978次,点赞25次,收藏21次。在Centos上安装Red...
文章浏览阅读1.2k次,点赞21次,收藏22次。Docker-Compose部...
文章浏览阅读2.2k次,点赞59次,收藏38次。合理的JedisPool资...