菜单

redis事务

2020年2月5日 - 计算机数据
redis事务

事务是一个数据库必备的元素,对于redis也不例外,对于一个传统的关系型数据库来说,数据库事务满足ACID四个特性:

redis事务

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. 执行事务。

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

然而,对于redis来说,只满足其中的:

开始事务

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

redis> MULTI
OK

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

图片 1

一致性和隔离性两个特性,其他特性是不支持的。

命令入队

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

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

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

图片 2

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

举个例子, 如果客户端执行以下命令:

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

关于redis对ACID四个特性暂时先说这么多,在本文后面会详细说明。在详述之前,我们先来了解redis事务具体的使用和实现,这样我们接下来讨论ACID时才能更好的理解。

执行事务

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

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

图片 3

如果客户端正处于事务状态, 那么当 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事务的使用

redis事务主要包括MULTI、EXEC、DISCARD和WATCH命令

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

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

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

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

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

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

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

MULTI命令

MULTI命令用来开启一个事务,当MULTI执行之后,客户端可以继续向服务器发送多条命令,这些命令会缓存在队列里面,只有当执行EXEC命令时,这些命令才会执行。

而DISCARD命令可以清空事务队列,放弃执行事务。

一个使用MULTI和EXEC执行事务的例子:

> MULTIOK> INCR fooQUEUED> INCR barQUEUED> EXEC1) (integer) 12) (integer) 1

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

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

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

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

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

redis事务产生错误

使用redis事务可能会产生错误,主要分为两大类:

redis在2.6.5之后,如果发现事务在执行EXEC之前出现错误,那么会放弃这个事务。

在EXEC命令之后产生的错误,会被忽略,其他正确的命令会被继续执行。

带 WATCH 的事务

WATCH 命令用于在事务开始之前监视任意数量的键: 当调用 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
的实现机制,并且看看事务系统是如何检查某个被监视的键是否被修改,从而保证事务的安全性的。

redis事务不支持回滚

如果你有使用关系式数据库的经验, 那么 “Redis
在事务失败时不进行回滚,而是继续执行余下的命令”这种做法可能会让你觉得有点奇怪。

以下是这种做法的优点:

鉴于没有任何机制能避免程序员自己造成的错误,
并且这类错误通常不会在生产环境中出现, 所以 Redis
选择了更简单、更快速的无回滚方式来处理事务。

WATCH 命令的实现

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

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

图片 4

其中, 键 key1 正在被 client2 、 client5 和 client1 三个客户端监视,
其他一些键也分别被其他别的客户端监视着。

WATCH 命令的作用, 就是将当前客户端和要监视的键在 watched_keys
中进行关联。

举个例子, 如果当前客户端为 client10086 , 那么当客户端执行 WATCH key1
key2 时, 前面展示的 watched_keys 将被修改成这个样子:

图片 5

通过 watched_keys 字典, 如果程序想检查某个键是否被监视,
那么它只要检查字典中是否存在这个键即可;
如果程序要获取监视某个键的所有客户端, 那么只要取出键的值(一个链表),
然后对链表进行遍历即可。

关于WATCH命令

WATCH命令可以添加监控的键,如果这些监控的键没有被其他客户端修改,那么事务可以顺利执行,如果被修改了,那么事务就不能执行。

WATCH 的触发

在任何对数据库键空间(key space)进行修改的命令成功执行之后 (比如
FLUSHDB 、 SET 、 DEL 、 LPUSH 、 SADD 、 ZREM ,诸如此类),
multi.c/touchWatchedKey 函数都会被调用 —— 它检查数据库的 watched_keys
字典, 看是否有客户端在监视已经被命令修改的键, 如果有的话,
程序将所有监视这个/这些被修改键的客户端的 REDIS_DIRTY_CAS 选项打开:

图片 6

当客户端发送 EXEC 命令、触发事务执行时,
服务器会对客户端的状态进行检查:

如果客户端的 REDIS_DIRTY_CAS
选项已经被打开,那么说明被客户端监视的键至少有一个已经被修改了,事务的安全性已经被破坏。服务器会放弃执行这个事务,直接向客户端返回空回复,表示事务执行失败。
如果 REDIS_DIRTY_CAS
选项没有被打开,那么说明所有监视键都安全,服务器正式执行事务。
可以用一段伪代码来表示这个检查:

def check_safety_before_execute_trasaction():

    if client.state & REDIS_DIRTY_CAS:
        # 安全性已破坏,清除事务状态
        clear_transaction_state(client)
        # 清空事务队列
        clear_transaction_queue(client)
        # 返回空回复给客户端
        send_empty_reply(client)
    else:
        # 安全性完好,执行事务
        execute_transaction()

举个例子,假设数据库的 watched_keys 字典如下图所示:

图片 7

如果某个客户端对 key1 进行了修改(比如执行 DEL key1 ), 那么所有监视
key1 的客户端, 包括 client2 、 client5 和 client1 的 REDIS_DIRTY_CAS
选项都会被打开, 当客户端 client2 、 client5 和 client1 执行 EXEC
的时候, 它们的事务都会以失败告终。

最后,当一个客户端结束它的事务时,无论事务是成功执行,还是失败,
watched_keys 字典中和这个客户端相关的资料都会被清除。

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图