Redis的事务控制命令、常见执行情况及watch机制

最新推荐文章于 2025-03-17 17:58:34 发布

Piconjo_Official

最新推荐文章于 2025-03-17 17:58:34 发布

阅读量8k

点赞数 1

分类专栏：数据库文章标签： redis 数据库编程语言缓存

本文链接：https://blog.youkuaiyun.com/Piconjo/article/details/104862256

版权

数据库专栏收录该内容

12 篇文章

订阅专栏

本文深入解析Redis事务(transaction)概念，包括事务的开启、命令执行、取消及Watch机制。阐述了Redis事务如何确保命令序列的完整执行，以及在遇到错误时的处理方式。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

概念：

事务是指一系列操作步骤中这一系列的操作步骤要么完全执行要么完全不执行
例如：微博的A用户关注了B用户那么A的关注人列表中就会出现B用户 B用户的粉丝列表中就会有A用户

这个关注和被关注的过程是由一系列的操作步骤组成的：
1、A用户添加到B用户的粉丝列表中
2、B用户添加到A用户多关注列表中
这两个步骤必须全部执行成功整个逻辑才是正确的否则会产生数据的错误例如：A用户的关注列表中有B用户但B用户的粉丝列表中没有A用户

为了确保一系列的操作完全成功提出了事务控制的概念

Redis的事务(transaction)是一组命令的集合 且至少是两个或两个以上的命令
Redis的事务确保了这些命令在被执行的时候不会被任何其它操作打断
单个 Redis 命令的执行是原子性的但 Redis 没有在事务上增加任何维持原子性的机制因此Redis事务的执行并不是原子性的

事务可以理解为一个打包的批量执行脚本但批量指令并非原子化的操作中间某条指令的失败不会导致前面已做指令的回滚也不会造成后续的指令的停止

二、命令

标记一个事务块的开始 ------> 即开启事务(beginTransaction)
事务内的多条命令会按照先后顺序被放入一个队列中
返回值：OK

multi

执行所有事务块内的命令 ------> 即提交(commit)
返回值：事务内的所有执行语句的内容
事务被打断则返回null

exec

取消事务 ------> 即回滚(rollback)
放弃执行事务块内的所有命令
返回值：OK

discard

监视一个或多个key
若在事务执行之前这个或这些key被其他命令所改动那么事务将被打断
返回值：OK

watch key [key ...]

取消watch命令对所有key的监视
若watch之后exec命令或discard命令被执行了则无须再执行unwatch命令了
因为此时事务内的命令已被执行了 unwatch没有意义了
返回值：OK

unwatch

三、执行情况

情况1、正常执行步骤

首先开启事务然后向事务队列中加入命令最后执行事务提交

1）multi：用 multi 命令告诉Redis接下来要执行的命令先不要执行而是暂时存起来（开启事务）
2）sadd classmate Piconjo：第一条命令进入等待队列（命令入队）
3）sadd classmate Tankman：第二条命令进入等待队列（命令入队）
4）exce：告知redis执行前面储存的命令

情况2、事务执行exec之前入队命令错误放弃事务

1）multi：正常命令
2）set：正常命令
3）incr：命令语法错误
4）exec：无法执行事务第一条正确的命令也不会执行

情况3、事务执行exec命令后执行队列中的命令时发生命令执行错误事务提交

1）multi：正常命令
2）set：正常命令
3）lpop classmate：语法没有错误执行时才会有错误
4）exec：正常执行发现错误则不执行该事务其余事务还是会执行

在这里插入图片描述
在exec执行后的所产生的错误即使事务中有某个或某些命令在执行时产生了错误
事务中的其他命令仍然会继续执行
Redis在事务失败时不进行回滚而是继续执行余下的命令

Redis命令只会因错误的语法而失败(这些问题不能在入队时发现) 或是命令用在了错误类型的键上面
由于失败的命令并不是Redis导致而是由编程错误造成的况且这样的错误应该在开发的过程中被发现
生产环境中不应出现语法的错误就是在程序的运行环境中也不应该出现语法的错误
Redis能够保证正确的命令一定会被执行
不需要对回滚进行支持也是为了保证Redis的内部保持简单且快速