【Redis】事务

最新推荐文章于 2025-08-16 00:13:43 发布

好想有猫猫

最新推荐文章于 2025-08-16 00:13:43 发布

阅读量808

点赞数 20

CC 4.0 BY-SA版权

分类专栏： Redis 文章标签： redis android 数据库 c++ 学习缓存

本文链接：https://blog.csdn.net/m0_72563041/article/details/149301137

Redis 专栏收录该内容

10 篇文章

订阅专栏

文章目录

事务
使用
小结

在这里插入图片描述

事务

关于事务，我们可能更熟悉 MySQL 的事务，这里先介绍 MySQL 事务的四大特性

原子性：把多个操作打包成一个整体，要么全部执行成功，要么全部执行失败。如果执行到中间的操作，失败了则需要把前面操作进行回退
一致性：事务执行之前和之后，数据不会出错
持久性：事务所做的修改都会保存硬盘
隔离性：事务并发执行涉及的一些问题，比如一个事务执行过程中是否可以看到另一个事务执行中或执行后的结果

Redis 的事务在概念上和 MySQL 事务是类似的，都是把一系列操作绑定成一组，让这一组能够批量执行
但要注意二者的区别：

Redis 事务

弱原子性：Redis 没有回滚机制，只能做到打包批量执行，不能做到一个失败就恢复到初始状态
不保证一致性：不涉及约束，也没有回滚，MySQL 的一致性是体现在事务运行前和运行后，结果都合理有效，不会出现中间非法状态
不需要持久性：数据保存在内存中，虽然有持久化，但是是服务端对数据的持久化，和事务无关
没有隔离性：没有隔离级别，因为 Redis 是单线程，并不会并发执行事务

Redis 事务本质是，服务器给每个客户端准备一个事务队列，客户端开启事务后，执行的每一个操作，服务端会先放到事务队列中，并不会立即执行
在客户端结束事务后，服务端将该客户端事务队列中的操作按照顺序依次执行

因此，Redis 的事务相比 MySQL，是弱化很多的，只能保证打包批量执行，不会被其他客户端抢占
因为 Redis 更注重效率，所以没有将事务设计的全面和复杂，MySQL 事务强大的背后是更多的空间和时间开销

使用

首先，Redis 是支持 lua 脚本的，可以通过 lua + 事务适配更好的并发场景
其次，集群模式下，Redis 是不支持事务的

命令

MULTI 开启事务

开启一个事务，执行成功返回 OK

127.0.0.1:6379> multi
OK

事务中的命令都会被添加到服务端的事务队列
此时其他 redis 客户端看不到执行命令的结果，因为命令其实还没执行
而本客户端也看不到此时的数据，因为所有命令都会被添加到事务队列，并为执行，所以不会得到服务端响应

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set key1 111
QUEUED
127.0.0.1:6379> set key2 222
QUEUED
127.0.0.1:6379> set key3 333
QUEUED
127.0.0.1:6379> keys *
QUEUED

每次添加一个操作，都会提示QUEUED，说明命令已经进入客户端队列

EXEC 执行事务

服务端收到该命令后，将该客户端事务队列的命令按顺序执行

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set key1 111
QUEUED
127.0.0.1:6379> set key2 222
QUEUED
127.0.0.1:6379> set key3 333
QUEUED
127.0.0.1:6379> keys *
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) OK
4) 1) "key1"
   2) "key"
   3) "x"
   4) "key2"
   5) "key3"

DISCARD 放弃事务

放弃当前事务，此时直接情况事务队列，之前的操作并不会真正执行

127.0.0.:16379> multi
OK
127.0.0.:16379> set k1 1
QUEUED
127.0.0.:16379> set k2 2
QUEUED
127.0.0.:16379> discard
OK

当开启事务后，并且有事务队列有若干命令时，如果服务器重启或者挂掉，那么事务会被丢弃，效果等同于 discard

WATCH

可能会有如下场景：

在这里插入图片描述

虽然从时间轴上看，是客户端1先对 key 进行修改，但是因为执行事务的时机比客户端2晚，所以实际修改是客户端1后于客户端2

这可能会造成数据上的错误，Redis 通过watch规避这类场景的出现

watch用于监控一个 key 是否在执行事务期间被其他客户端修改，如果修改，那么最后执行事务时会报错，不执行事务

watch底层是通过给 key 分配版本号实现监控效果，流程如下：

在执行事务前，对 key 进行 watch，分配一个版本号并记录
开启事务
multi之后，exec 之前，如果有其他客户端对 watch 的 key 进行了修改，那么其版本号会变大
执行 exec后，不管事务期间有没有对监控的 key 进行修改，都会判断其版本号与记录是否相同，相同则说明没有其他客户端对其进行修改，事务执行成功；反之如果版本号不同，则不实际执行事务，返回 nil