【redis】redis的事务

最新推荐文章于 2025-12-04 18:16:22 发布

原创最新推荐文章于 2025-12-04 18:16:22 发布 · 147 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#redis #数据库 #缓存

Redis 专栏收录该内容

23 篇文章

订阅专栏

Redis支持简单的事务机制，通过MULTI、EXEC、DISCARD和UNWATCH命令进行操作。在事务中，命令被存储并顺序执行。当两个事务并发执行时，可能出现数据冲突。例如，用户A开启事务设置K1的值，而用户B在同一时间开启事务并删除K1，B的事务先执行，导致A的事务执行时K1已不存在。为解决这类问题，可以使用WATCH命令来监控关键键，确保其在事务执行前未被修改，以保证数据一致性。

redis支持事务，这种事务是比较简单的事务。
命令如下：

127.0.0.1:6379> help @transactions

  DISCARD 
  summary: Discard all commands issued after MULTI
  since: 2.0.0

  EXEC 
  summary: Execute all commands issued after MULTI
  since: 1.2.0

  MULTI 
  summary: Mark the start of a transaction block
  since: 1.2.0

  UNWATCH 
  summary: Forget about all watched keys
  since: 2.2.0

  WATCH key [key ...]
  summary: Watch the given keys to determine execution of the MULTI/EXEC block
  since: 2.2.0

使用multi命令开启一个事务，随后可以发送一个个的命令，最后发送一个命令exec可以执行命令。由multi开启事务后，exec之前multi之后的命令，都会被存储在一个队列中，当exec命令后，会顺序的一次性执行完整个队列中的命令。

127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) OK

2个事务紧挨着开启，会出现什么情况，示例如下
用户A将K1的值设置为v1，开启一个事务，展示所有key，但还没有执行

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> keys *
QUEUED

用户B再用户A几乎与用户A同时开启事务，并且用户B先提交了exec命令执行事务。

127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> del k1
QUEUED
127.0.0.1:6379(TX)> exec
1) (integer) 1

此时用户A显示如下

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> keys *
QUEUED
127.0.0.1:6379(TX)> exec
1) (empty array)

由于k1已经被用户B先提交事务删除掉了，所以展示的keys *为空。

在用户使用multi开启事务时，到最后exec执行事务，期间可能有其他线程先行改变了用户事务中的某些key。如果你不希望这些key在执行事务时是被其他用户修改过的，可以使用watch。
在multi之前，先watch key，这样，事务就会变得有条件的执行，前提条件就是watch的key不能被改变，如果key被改变，整个事务就会放弃执行。

参考文章：
[1]，事务