事务

Redis 通过 MULTI 、 DISCARD 、 EXEC 和 WATCH 四个命令来实现事务功能，本章首先讨论使用 MULTI 、 DISCARD 和 EXEC 三个命令实现的一般事务，然后再来讨论带有 WATCH 的事务的实现。

因为事务的安全性也非常重要，所以本章最后通过常见的 ACID 性质对 Redis 事务的安全性进行了说明。

事务

事务提供了一种“将多个命令打包，然后一次性、按顺序地执行”的机制，并且事务在执行的期间不会主动中断 ——服务器在执行完事务中的所有命令之后，才会继续处理其他客户端的其他命令。

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

redis> MULTI
OK

redis> SET book-name "Mastering C++ in 21 days"
QUEUED

redis> GET book-name
QUEUED

redis> SADD tag "C++" "Programming" "Mastering Series"
QUEUED

redis> SMEMBERS tag
QUEUED

redis> EXEC
1) OK
2) "Mastering C++ in 21 days"
3) (integer) 3
4) 1) "Mastering Series"
   2) "C++"
   3) "Programming"

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

1. 开始事务。
2. 命令入队。
3. 执行事务。

下文将分别介绍事务的这三个阶段。

开始事务

MULTI 命令的执行标记着事务的开始：

redis> MULTI
OK

这个命令唯一做的就是，将客户端的 REDIS_MULTI 选项打开，让客户端从非事务状态切换到事务状态。

transaction [label = "打开选项\nREDIS_MULTI"];}" />

命令入队

当客户端处于非事务状态下时，所有发送给服务器端的命令都会立即被服务器执行：

redis> SET msg "hello moto"
OK

redis> GET msg
"hello moto"

但是，当客户端进入事务状态之后，服务器在收到来自客户端的命令时，不会立即执行命令，而是将这些命令全部放进一个事务队列里，然后返回 QUEUED ，表示命令已入队：

redis> MULTI
OK

redis> SET msg "hello moto"
QUEUED

redis> GET msg
QUEUED

以下流程图展示了这一行为：

in_transaction_or_not; in_transaction_or_not -> enqueu_command [label = "是"]; in_transaction_or_not -> exec_command [label = "否"]; exec_command -> return_command_result; enqueu_command -> return_enqueued;}" />

事务队列是一个数组，每个数组项是都包含三个属性：

1. 要执行的命令（cmd）。
2. 命令的参数（argv）。
3. 参数的个数（argc）。

举个例子，如果客户端执行以下命令：

redis> MULTI
OK

redis> SET book-name "Mastering C++ in 21 days"
QUEUED

redis> GET book-name
QUEUED

redis> SADD tag "C++" "Programming" "Mastering Series"
QUEUED

redis> SMEMBERS tag
QUEUED

那么程序将为客户端创建以下事务队列：

数组索引	cmd	argv	argc
0	SET	["book-name", "Mastering C++ in 21 days"]	2
1	GET	["book-name"]	1
2	SADD	["tag", "C++", "Programming", "Mastering Series"]	4
3	SMEMBERS	["tag"]	1

执行事务

前面说到，当客户端进入事务状态之后，客户端发送的命令就会被放进事务队列里。

但其实并不是所有的命令都会被放进事务队列，其中的例外就是 EXEC 、 DISCARD 、 MULTI 和 WATCH 这四个命令 ——当这四个命令从客户端发送到服务器时，它们会像客户端处于非事务状态一样，直接被服务器执行：

in_transaction_or_not; in_transaction_or_not -> not_exec_and_discard [label = "是"]; not_exec_and_discard -> enqueu_command [label = "否"]; not_exec_and_discard -> exec_command [label = "是"]; in_transaction_or_not -> exec_command [label = "否"]; exec_command -> return_command_result; enqueu_command -> return_enqueued;}" />

如果客户端正处于事务状态，那么当 EXEC 命令执行时，服务器根据客户端所保存的事务队列，以先进先出（FIFO）的方式执行事务队列中的命令：最先入队的命令最先执行，而最后入队的命令最后执行。

比如说，对于以下事务队列：

数组索引	cmd	argv	argc
0	SET	["book-name", "Mastering C++ in 21 days"]	2
1	GET	["book-name"]	1
2	SADD	["tag", "C++", "Programming", "Mastering Series"]	4
3	SMEMBERS	["tag"]	1

程序会首先执行 SET 命令，然后执行 GET 命令，再然后执行 SADD 命令，最后执行 SMEMBERS 命令。

执行事务中的命令所得的结果会以 FIFO 的顺序保存到一个回复队列中。

比如说，对于上面给出的事务队列，程序将为队列中的命令创建如下回复队列：

数组索引	回复类型	回复内容
0	status code reply	OK
1	bulk reply	"Mastering C++ in 21 days"
2	integer reply	3
3	multi-bulk reply	["Mastering Series", "C++", "Programming"]

当事务队列里的所有命令被执行完之后，EXEC 命令会将回复队列作为自己的执行结果返回给客户端，客户端从事务状态返回到非事务状态，至此，事务执行完毕。

事务的整个执行过程可以用以下伪代码表示：

def execute_transaction():

    # 创建空白的回复队列
    reply_queue = []

    # 取出事务队列里的所有命令、参数和参数数量
    for cmd, argv, argc in client.transaction_queue:

        # 执行命令，并取得命令的返回值
        reply = execute_redis_command(cmd, argv, argc)

        # 将返回值追加到回复队列末尾
        reply_queue.append(reply)

    # 清除客户端的事务状态
    clear_transaction_state(client)

    # 清空事务队列
    clear_transaction_queue(client)

    # 将事务的执行结果返回给客户端
    send_reply_to_client(client, reply_queue)

在事务和非事务状态下执行命令

无论在事务状态下，还是在非事务状态下，Redis 命令都由同一个函数执行，所以它们共享很多服务器的一般设置，比如 AOF 的配置、RDB 的配置，以及内存限制，等等。

不过事务中的命令和普通命令在执行上还是有一点区别的，其中最重要的两点是：

1. 非事务状态下的命令以单个命令为单位执行，前一个命令和后一个命令的客户端不一定是同一个；

而事务状态则是以一个事务为单位，执行事务队列中的所有命令：除非当前事务执行完毕，否则服务器不会中断事务，也不会执行其他客户端的其他命令。

1. 在非事务状态下，执行命令所得的结果会立即被返回给客户端；

而事务则是将所有命令的结果集合到回复队列，再作为 EXEC 命令的结果返回给客户端。

事务状态下的 DISCARD 、 MULTI 和 WATCH 命令

除了 EXEC 之外，服务器在客户端处于事务状态时，不加入到事务队列而直接执行的另外三个命令是 DISCARD 、 MULTI 和 WATCH 。

DISCARD 命令用于取消一个事务，它清空客户端的整个事务队列，然后将客户端从事务状态调整回非事务状态，最后返回字符串 OK 给客户端，说明事务已被取消。

Redis 的事务是不可嵌套的，当客户端已经处于事务状态，而客户端又再向服务器发送 MULTI 时，服务器只是简单地向客户端发送一个错误，然后继续等待其他命令的入队。MULTI 命令的发送不会造成整个事务失败，也不会修改事务队列中已有的数据。

WATCH 只能在客户端进入事务状态之前执行，在事务状态下发送 WATCH 命令会引发一个错误，但它不会造成整个事务失败，也不会修改事务队列中已有的数据（和前面处理 MULTI 的情况一样）。

带 WATCH 的事务

WATCH [http://redis.readthedocs.org/en/latest/transaction/watch.html#watch] 命令用于在事务开始之前监视任意数量的键：当调用 EXEC [http://redis.readthedocs.org/en/latest/transaction/exec.html#exec] 命令执行事务时，如果任意一个被监视的键已经被其他客户端修改了，那么整个事务不再执行，直接返回失败。

以下示例展示了一个执行失败的事务例子：

redis> WATCH name
OK

redis> MULTI
OK

redis> SET name peter
QUEUED

redis> EXEC
(nil)

以下执行序列展示了上面的例子是如何失败的：

时间	客户端 A	客户端 B
T1	WATCH name
T2	MULTI
T3	SET name peter
T4		SET name john
T5	EXEC

在时间 T4 ，客户端 B 修改了 name 键的值，当客户端 A 在 T5 执行 EXEC 时，Redis 会发现 name 这个被监视的键已经被修改，因此客户端 A 的事务不会被执行，而是直接返回失败。

下文就来介绍 WATCH 的实现机制，并且看看事务系统是如何检查某个被监视的键是否被修改，从而保证事务的安全性的。

WATCH 命令的实现

在每个代表数据库的 redis.h/redisDb 结构类型中，都保存了一个 watched_keys 字典，字典的键是这个数据库被监视的键，而字典的值则是一个链表，链表中保存了所有监视这个键的客户端。

比如说，以下字典就展示了一个 watched_keys 字典的例子：