【redis】redis的事务

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]，事务