Redis 事务是否具备原子性？

最新推荐文章于 2024-09-25 00:09:55 发布
置顶 最新推荐文章于 2024-09-25 00:09:55 发布
阅读量2.5k 收藏 6
点赞数 8
分类专栏： Redis 文章标签： Redis 事务的设计与实现 原子性 事务队列
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Howinfun/article/details/105753716
版权

一、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、命令入队

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

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

  • 如果客户端发送的命令为 EXEC、DISCARD、WATCH、MULTI 四个命令的其中一个，那么服务器立即执行这个命令。

  • 与此相反，如果客户端发送的命令是 EXEC、DISCARD、WATCH、MULTI 四个命令以外的其他命令，那么服务器并不立即执行这个命令。

    • 首先检查此命令的格式是否正确，如果不正确，服务器会在客户端状态（redisClient）的 flags 属性打开 REDIS_MULTI 标识，并且返回错误信息给客户端。
    • 如果正确将这个命令放入一个事务队列里面，然后向客户端返回 QUEUED 回复。
我们先看看事务队列是如何实现的？

每个 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 命令逻辑。

  • 如果客户端状态的 flags 属性不包含 REDIS_MULTI 标识，或者包含 REDIS_DIRTY_CAS 或者 REDIS_DIRTY_EXEC 标识，那么就直接取消事务的执行。
  • 否则客户端处于事务状态（flags 有 REDIS_MULTI 标识），服务器会遍历客户端的事务队列，然后执行事务队列中的所有命令，最后将返回结果全部返回给客户端；
void execCommand(redisClient *c) {
    int j;
    robj **orig_argv;
    int orig_argc;
    struct redisCommand *orig_cmd;
    int must_propagate = 0; /* Need to propagate MULTI/EXEC to AOF / slaves? */

    // 客户端没有执行事务
    if (!(c->flags & REDIS_MULTI)) {
        addReplyError(c,"EXEC without MULTI");
        return;
    }

    /* Check if we need to abort the EXEC because:
     *
     * 检查是否需要阻止事务执行，因为：
     *
     * 1) Some WATCHed key was touched.
     *    有被监视的键已经被修改了
     *
     * 2) There was a previous error while queueing commands.
     *    命令在入队时发生错误
     *    （注意这个行为是 2.6.4 以后才修改的，之前是静默处理入队出错命令）
     *
     * A failed EXEC in the first case returns a multi bulk nil object
     * (technically it is not an error but a special behavior), while
     * in the second an EXECABORT error is returned. 
     *
     * 第一种情况返回多个批量回复的空对象
     * 而第二种情况则返回一个 EXECABORT 错误
     */
    if (c->flags & (REDIS_DIRTY_CAS|REDIS_DIRTY_EXEC)) {

        addReply(c, c->flags & REDIS_DIRTY_EXEC ? shared.execaborterr :
                                                  shared.nullmultibulk);

        // 取消事务
        discardTransaction(c);

        goto handle_monitor;
    }

    /* Exec all the queued commands */
    // 已经可以保证安全性了，取消客户端对所有键的监视
    unwatchAllKeys(c); /* Unwatch ASAP otherwise we'll waste CPU cycles */

    // 因为事务中的命令在执行时可能会修改命令和命令的参数
    // 所以为了正确地传播命令，需要现备份这些命令和参数
    orig_argv = c->argv;
    orig_argc = c->argc;
    orig_cmd = c->cmd;

    addReplyMultiBulkLen(c,c->mstate.count);

    // 执行事务中的命令
    for (j = 0; j < c->mstate.count; j++) {

        // 因为 Redis 的命令必须在客户端的上下文中执行
        // 所以要将事务队列中的命令、命令参数等设置给客户端
        c->argc = c->mstate.commands[j].argc;
        c->argv = c->mstate.commands[j].argv;
        c->cmd = c->mstate.commands[j].cmd;

        /* Propagate a MULTI request once we encounter the first write op.
         *
         * 当遇上第一个写命令时，传播 MULTI 命令。
         *
         * This way we'll deliver the MULTI/..../EXEC block as a whole and
         * both the AOF and the replication link will have the same consistency
         * and atomicity guarantees. 
         *
         * 这可以确保服务器和 AOF 文件以及附属节点的数据一致性。
         */
        if (!must_propagate && !(c->cmd->flags & REDIS_CMD_READONLY)) {

            // 传播 MULTI 命令
            execCommandPropagateMulti(c);

            // 计数器，只发送一次
            must_propagate = 1;
        }

        // 执行命令
        call(c,REDIS_CALL_FULL);

        /* Commands may alter argc/argv, restore mstate. */
        // 因为执行后命令、命令参数可能会被改变
        // 比如 SPOP 会被改写为 SREM
        // 所以这里需要更新事务队列中的命令和参数
        // 确保附属节点和 AOF 的数据一致性
        c->mstate.commands[j].argc = c->argc;
        c->mstate.commands[j].argv = c->argv;
        c->mstate.commands[j].cmd = c->cmd;
    }

    // 还原命令、命令参数
    c->argv = orig_argv;
    c->argc = orig_argc;
    c->cmd = orig_cmd;

    // 清理事务状态
    discardTransaction(c);

    /* Make sure the EXEC command will be propagated as well if MULTI
     * was already propagated. */
    // 将服务器设为脏，确保 EXEC 命令也会被传播
    if (must_propagate) server.dirty++;

handle_monitor:
    /* Send EXEC to clients waiting data from MONITOR. We do it here
     * since the natural order of commands execution is actually:
     * MUTLI, EXEC, ... commands inside transaction ...
     * Instead EXEC is flagged as REDIS_CMD_SKIP_MONITOR in the command
     * table, and we do it here with correct ordering. */
    if (listLength(server.monitors) && !server.loading)
        replicationFeedMonitors(c,server.monitors,c->db->id,c->argv,c->argc);
}

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

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

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

下面我们演示一下：

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

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

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

我们下面演示一下：

全部执行成功的：
在这里插入图片描述
一个都不执行：
在这里插入图片描述
这就是上面提到的，在事务开始后，用户可以输入事务要执行的命令；在命令入事务队列前，会对命令进行检查，如果命令不存在或者是命令参数不对，则会返回错误可客户端，并且修改客户端状态。

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

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

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

我很赞同 Redis 作者的想法：

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

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

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

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

所以最后，其实 Redis 事务真正支持原子性的前提：开发者不要傻不拉几的写有逻辑问题的代码！

参考资料：《Redis 设计与实现》、《Redis 源码》

Howinfun
关注
专栏目录
事务机制：Redis能实现ACID属性吗？
阅读之后，对你有帮助，那就点个赞再走吧
07-18 182
事务是数据库的一个重要功能。所谓的事务，就是指对数据进行读写的一系列操作。事务在执行时，会提供专门的属性保证，包括原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability），也就是ACID属性。这些属性既包括了对事务执行结果的要求，也有对数据库在事务执行前后的数据状态变化的要求。那么，Redis可以完全保证ACID属性吗？...
Redis中的事务可以满足ACID属性吗？
程序媛小琬的博客
12-02 1357
事务是数据库操作的最小工作单元，由一个有限的数据库操作序列构成。这些操作要么全部执行，要么全部不执行，是一个不可分割的工作单位。
【高频 Redis 面试题】Redis 事务是否具备原子性？
01-19
一、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);
面试官：Redis的事务满足原子性吗？
09-09 870
原创：码农参上（微信公众号ID：CODER_SANJYOU），欢迎分享，转载请保留出处。 谈起数据库的事务来，估计很多同学的第一反应都是ACID，而排在ACID中首位的A原子性，要求一个事务中的所有操作，要么全部完成，要么全部不完成。熟悉redis的同学肯定知道，在redis中也存在事务，那么它的事务也满足原子性吗？下面我们就来一探究竟。 什么是Redis事务？ 和数据库事务类似，redis事务也是用来一次性地执行多条命令。使用起来也很简单，可以用MULTI开启一个事务，然后将多个命令入队到事务的队列中.
[Redis][事务]详细讲解
最新发布
SnowK博客
09-25 4560
[Redis][事务]详细讲解
解密Redis事务（redis事务有没有原子性）
怪力乌龟的博客
11-11 2819
事务是什么意思 事务：是数据库操作的最小工作单元，是作为单个逻辑工作单元执行的一系列操作；这些操作作为一个整体一起向系统提交，要么都执行、要么都不执行；事务是一组不可再分割的操作集合（工作逻辑单元）； 事务的四大特性： 原子性 事务是数据库的逻辑工作单位，事务中包含的各操作要么都做，要么都不做 一致性 事 务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统 运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事
Redis 的事务满足原子性吗？
crg18438610577的博客
05-15 506
Redis 的事务满足原子性吗？
Redis事务详解：原子性、隔离操作与命令示例
但是，这并不意味着 Redis 事务具有像 ACID（原子性、一致性、隔离性、持久性）那样的标准事务特性。 2. **事务的特性** - **非隔离级别**：Redis 事务中不存在隔离级别的概念。在事务提交之前，队列中的命令不会...
说说 Redis 事务
Q54665642ljf的博客
10-29 1407
Redis 只是提供了简单的事务功能。其本质是一组命令的集合，事务支持一次执行多个命令，在事务执行过程中，会顺序执行队列中的命令，其他客户端提交的命令请求不会插入到本事务执行命令序列中。命令的执行过程是顺序执行的，但不能保证原子性。无法像 MySQL 那样，有隔离级别，出了问题之后还能回滚数据等高级操作。后面会详细分析。#本文主要介绍了 Redis 事务的基础指令与执行流程，并分析了其对传统 ACID 特性支持的情况，相信大家对 Redis 事务已经有了一个简单的了解。
Redis 事务
iteye_2022的博客
10-28 342
Redis 提供的事务机制与传统的数据库事务有些不同，传统数据库事务必须维护以下特性：原子性(Atomicity), 一致性(Consistency), 隔离性(Isolation), 持久性(Durability)，简称ACID。 我们逐项考察下 Redis 在事务的 ACID 上做出的权衡与取舍： 原子性(Atomicity) 原子意味着操作的不可再分，要么执行要么不执行。...
Redis的事务满足原子性吗？
ludongguoa的博客
11-06 223
谈起数据库的事务来，估计很多同学的第一反应都是ACID，而排在ACID中首位的A原子性，要求一个事务中的所有操作，要么全部完成，要么全部不完成。熟悉redis的同学肯定知道，在redis中也存在事务，那么它的事务也满足原子性吗？下面我们就来一探究竟。 什么是Redis事务？ 和数据库事务类似，redis事务也是用来一次性地执行多条命令。使用起来也很简单，可以用MULTI开启一个事务，然后将多个命令入队到事务的队列中，最后由EXEC命令触发事务，执行事务中的所有命令。看一个简单的事务执行例子： 127
「高频 Redis 面试题」Redis 事务是否具备原子性？看完本文你就能明白！
weixin_46898270的博客
05-25 233
一、事务的实现原理 一个事务从开始到结束通常会经历以下三个阶段： 1、事务开始 客户端发送 MULTI 命令，服务器执行 MULTI 命令逻辑。 服务器会在客户端状态（redisClient）的 flags 属性打开 REDIS_MULTI 标识，将客户端从非事务状态切换到事务状态。 2、命令入队 接着，用户可以在客户端输入当前事务要执行的多个命令。 当客户端切换到事务状态时，服务器会根据客户端发来的命令来执行不同的操作。 如果客户端发送的命令为 EXEC、DISCARD、WATCH、MULTI 四个命令
redis事务是否支持原子性
huchao_lingo的博客
04-01 3104
redis事务是否支持原子性 ACID 中关于原子性的定义： 原子性：一个事务（transaction）中的所有操作，或者全部完成，或者全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。即，事务不可分割、不可约简。 redis事务测试 127.0.0.1:6379> multi OK 127.0....
Redis事务是否支持原子性？
qq_44469202的博客
04-08 1797
Redis事务是否支持原子性？ 因为 Redis 事务不支持事务回滚机制，所以如果事务执行中出现了命令执行错误（例如对 String 类型的key执行 LPUSH 操作），只会返回当前命令执行的错误给客户端，并不会影响下面命令的执行。因此很多人就觉得和关系型数据库（MySQL） 不一样，所以大家认为 Redis 事务不支持原子性。 但其实Redis意义上支持原子性的。正常情况下，它也是要不所有命令执行成功，要不一个命令都不执行。即使 Redis 不支持事务回滚机制，但是它会检查每一个事务中的命令是否错误。
【Redis】redis事务的特性？真的没有原子性吗？
锥栗的博客
09-11 1401
Redis事务 事务的四大特性我们都知道是ACID：1. 原子性，2. 一致性，3. 隔离性，4. 持久性。 它们的定义如下： 1. 原子性：事务是程序执行的最小单位，事务中的命令要么全部一起执行，要么就都不执行（如果有一个命令不能执行，那所有命令不能执行）。 2. 一致性：数据在事务执行前后保持一致，所有事物对数据的读取结果相同。 3. 隔离性：事务在提交前，对其他事务不可见。 4.持久性：事务一旦提交，数据会永久保存，即使系统崩溃数据也不丢失。 由于Redis事务不支持回滚，很多人说因此Redis事务不
Redis的事物不能保证原子性
rlk512974883的博客
09-01 1083
一、我们redis数据库中，事务回事什么样子的呢？ 首先我们给出一个定义：redis的事务中，一次执行多条命令，本质是一组命令的集合，一个事务中所有的命令将被序列化，即按顺序执行而不会被其他命令插入 在redis中，事务的作用就是在一个队列中一次性、顺序性、排他性的执行一系列的命令。 事务的生命周期： 1. 事务的创建：使用MULTI开启一个事务 2. 加入队列：在开启事务的时候，每次操作的命令将会被插入到一个队列中，同时这个命令并不会被真的执行 3. EXEC命令进行提交事务 常用的关于事务
Redis 事务 不是原子性的！
CmdSmith的博客
01-14 1388
单个Redis命令的执行是原子性的，但Redis没有在事务上增加任何维持原子性的机制，所以Redis事务的执行并不是原子性。 事务可以理解为一个打包的批量执行脚本，但批量执行并非原子化的操作，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续指令不做。 这是官网上的说明 From redis docs on transactions: It’s important to note ...
评论 4
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值