高频Redis面试题解析:Redis 事务是否具备原子性?
2020/04/28 19:49:28 来源:https://blog.51cto.com/14799494/2490313 作者:wx5e9fc52a5db79

一、Redis 事务的实现原理

一个事务从开始到结束通常会经历以下三个阶段:

1、事务开始

客户端发送 MULTI 命令,服务器执行 MULTI 命令逻辑。

服务器会在客户端状态(redisClient)的 flags 属性打开 REDIS_MULTI 标识,将客户端从非事务状态切换到事务状态。

void multiCommand(redisClient *c) {
    // 不能在事务中嵌套事务
    if (c->flags & REDIS_MULTI) {
        addReplyError(c,"MULTI calls can not be nested");
        return;
    }
    // 打开事务 FLAG
    c->flags |= REDIS_MULTI;
    addReply(c,shared.ok);
}

2、命令入队

接着,用户可以在客户端输入当前事务要执行的多个命令。

当客户端切换到事务状态时,服务器会根据客户端发来的命令来执行不同的操作。

我们先看看事务队列是如何实现的

每个 Redis 客户端都有自己的事务状态,对应的是客户端状态(redisClient)的 mstate 属性。

typeof struct redisClient{
    // 事务状态
    multiState mstate;
}
redisClient;

事务状态(mstate)包含一个事务队列(FIFO 队列),以及一个已入队命令的计数器。

/*
 * 事务状态
 */
typedef struct multiState {
    // 事务队列,FIFO 顺序
    multiCmd *commands;
    /* Array of MULTI commands */
    // 已入队命令计数
    int count;
    /* Total number of MULTI commands */
    int minreplicas;
    /* MINREPLICAS for synchronous replication */
    time_t minreplicas_timeout;
    /* MINREPLICAS timeout as unixtime. */
}
multiState;

事务队列是一个 multiCmd 类型数组,数组中每个 multiCmd 结构都保存了一个如入队命令的相关信息:指向命令实现函数的指针,命令的参数,以及参数的数量。

/*
 * 事务命令
 */
typedef struct multiCmd {
    // 参数
    robj **argv;
    // 参数数量
    int argc;
    // 命令指针
    struct redisCommand *cmd;
}
multiCmd;

最后我们再看看入队列的源码

/* Add a new command into the MULTI commands queue 
 *
 * 将一个新命令添加到事务队列中
 */
void queueMultiCommand(redisClient *c) {
    multiCmd *mc;
    int j;
    // 为新数组元素分配空间
    c->mstate.commands = zrealloc(c->mstate.commands,
                sizeof(multiCmd)*(c->mstate.count+1));
    // 指向新元素
    mc = c->mstate.commands+c->mstate.count;
    // 设置事务的命令、命令参数数量,以及命令的参数
    mc->cmd = c->cmd;
    mc->argc = c->argc;
    mc->argv = zmalloc(sizeof(robj*)*c->argc);
    memcpy(mc->argv,c->argv,sizeof(robj*)*c->argc);
    for (j = 0; j < c->argc; j++)
            incrRefCount(mc->argv[j]);
    // 事务命令数量计数器增一
    c->mstate.count++;
}

当然了,还有我们上面提到的,如果命令入队出错时,会打开客户端状态的 REDIS_DIRTY_EXEC 标识。

/* Flag the transacation as DIRTY_EXEC so that EXEC will fail.
 *
 * 将事务状态设为 DIRTY_EXEC ,让之后的 EXEC 命令失败。
 *
 * Should be called every time there is an error while queueing a command. 
 *
 * 每次在入队命令出错时调用
 */
void flagTransaction(redisClient *c) {
    if (c->flags & REDIS_MULTI)
            c->flags |= REDIS_DIRTY_EXEC;
}

3、事务执行

客户端发送 EXEC 命令,服务器执行 EXEC 命令逻辑。

二、为什么很多人说 Redis 事务为何不支持原子性?

1、Redis 事务不支持事务回滚机制

Redis 事务执行过程中,如果一个命令执行出错,那么就返回错误,然后还是会接着继续执行下面的命令。

下面我们演示一下:

高频Redis面试题解析:Redis 事务是否具备原子性?

正是因为 Redis 事务不支持事务回滚机制,如果事务执行中出现了命令执行错误(例如对 String 类型的数据库键执行 LPUSH 操作),只会返回当前命令执行的错误给客户端,并不会影响下面的命令的执行。所以很多人觉得和关系型数据库(MySQL) 不一样,而 MySQL 的事务是具有原子性的,所以大家都认为 Redis 事务不支持原子性。

2、但是其实 Redis 意义上是支持原子性的

正常情况下,它也是要不所有命令执行成功,要不一个命令都不执行。

我们下面演示一下:

全部执行成功的:

高频Redis面试题解析:Redis 事务是否具备原子性?

一个都不执行:

高频Redis面试题解析:Redis 事务是否具备原子性?

这就是上面提到的,在事务开始后,用户可以输入事务要执行的命令;在命令入事务队列前,会对命令进行检查,如果命令不存在或者是命令参数不对,则会返回错误可客户端,并且修改客户端状态。

当后面客户端执行 EXEC 命令时,服务器就会直接拒绝执行此事务了。

所以说,Redis 事务其实是支持原子性的!即使 Redis 不支持事务回滚机制,但是它会检查每一个事务中的命令是否错误。

但是我们要注意一个点就是:Redis 事务不支持检查那些程序员自己逻辑错误。例如对 String 类型的数据库键执行对 HashMap 类型的操作!

我很赞同 Redis 作者的想法

首先,MySQL 和 Redis 的定位不一样,一个是关系型数据库,一个是 NoSQL。

MySQL 的 SQL 查询是可以相当复杂的,而且 MySQL 没有事务队列这种说法,SQL 真正开始执行才会进行分析和检查,MySQL 不可能提前知道下一条 SQL 是否正确。所以支持事务回滚是非常有必要的~

但是,Redis 使用了事务队列来预先将执行命令存储起来,并且会对其进行格式检查的,提前就知道命令是否可执行了。所以如果只要有一个命令是错误的,那么这个事务是不能执行的。

Redis 作者认为基本只会出现在开发环境的编程错误其实在生产环境基本是不可能出现的(例如对 String 类型的数据库键执行 LPUSH 操作),所以他觉得没必要为了这事务回滚机制而改变 Redis 追求简单高效的设计主旨

Linux公社的RSS地址https://www.linuxidc.com/rssFeed.aspx

本文永久更新链接地址https://www.linuxidc.com/Linux/2020-04/163058.htm


7

本栏最新