九、【Redis】事务

目录

 

一、Redis 事务

二、实例

三、事务相关命令

---

一、Redis 事务

Redis 事务可以一次执行多个命令， 并且带有以下重要的保证：

• 批量操作在发送 EXEC 命令前被放入队列缓存。
• 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。
• 在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。

一个事务从开始到执行会经历以下三个阶段：

• 开始事务。
• 命令入队。
• 执行事务。

---

二、实例

以下是一个事务的例子， 它先以 MULTI 开始一个事务， 然后将多个命令入队到事务中， 最后由 EXEC 命令触发事务， 一并执行事务中的所有命令：

redis 127.0.0.1:6379> MULTI
OK
redis 127.0.0.1:6379> SET book "C++"
QUEUED
redis 127.0.0.1:6379> GET book
QUEUED
redis 127.0.0.1:6379> SADD tag "C++" "Programming"
QUEUED
redis 127.0.0.1:6379> SMEMBERS tag
QUEUED
redis 127.0.0.1:6379> EXEC
1) OK
2) "C++"
3) (integer) 2
4) 1) "C++"
   2) "Programming"

单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以 Redis 事务的执行并不是原子性的。

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

比如：

redis 127.0.0.1:7000> multi
OK
redis 127.0.0.1:7000> set a a
QUEUED
redis 127.0.0.1:7000> set b b
QUEUED
redis 127.0.0.1:7000> set c c
QUEUED
redis 127.0.0.1:7000> exec
1) OK
2) OK
3) OK

如果在 set b b 处失败，set a 已成功不会回滚，set c 还会继续执行。

假设此时车票 t 只有 1 张，而此时 user1 在买票的最后一步执行前票被 user2 买走了 ，情况如下：

这是user1的操作

127.0.0.1:6379> set t 1
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decr t
QUEUED

再打开一个命令行：user2 买票操作成功（票数减一），票剩余 0 张

127.0.0.1:6379> decr t
(integer) 0

再看 user1 ，执行事务

127.0.0.1:6379> set t 1
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decr t
QUEUED
127.0.0.1:6379> exec
1) (integer) -1

剩余 -1 张票了，事实是票数不能为负数

那么如何解决呢？

三、事务相关命令

Redis Watch 命令用于监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断

redis Watch 命令基本语法如下：

WATCH key [key ...]

解决以上问题只需要 监视 key也就是用watch 监视车票：

此时 user2 买票后， user1 就买不到票了，返回 nil，不再是 -2 了。

127.0.0.1:6379> set t 1
OK
127.0.0.1:6379> watch t
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decr t
QUEUED
127.0.0.1:6379> exec
(nil)

其他命令：

1	discard  取消事务，放弃执行事务块内的所有命令。
2	exec  执行所有事务块内的命令。
3	multi 标记一个事务块的开始。
4	unwatch 取消 WATCH 命令对所有 key 的监视。
5	watch key [key ...]  监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。

 

参考：菜鸟教程