Redis 事务

事务

Redis 通过 MULTIDISCARDEXECWATCH 四个命令来实现事务功能,本章首先讨论使用 MULTIDISCARDEXEC 三个命令实现的一般事务,然后再来讨论带有 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 选项打开,让客户端从非事务状态切换到事务状态。

digraph normal_to_trans {    rankdir = LR;    node [shape = circle, style = filled];    edge [style = bold];    label = 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

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

digraph enqueue {    node [shape = plaintext, style = filled];    edge [style = bold];    command_in [label = 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

执行事务

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

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

digraph not_enque_command {    node [shape = plaintext, style = filled];    edge [style = bold];    command_in [label = 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 之外,服务器在客户端处于事务状态时,不加入到事务队列而直接执行的另外三个命令是 DISCARDMULTIWATCH

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 字典的例子:

以上内容是否对您有帮助:
在线笔记
App下载
App下载

扫描二维码

下载编程狮App

公众号
微信公众号

编程狮公众号

返回顶部