Redis实例发生故障，而Redis使用RDB机制，事务的原子性能否得到保证？

关注

原创最新推荐文章于 2026-04-02 09:59:44 发布 504 阅读 AI 写同款· GEO 优化 ›

Redis——Redis如何保证数据一致性？ Redis 通过单线程操作、事务支持、持久化机制、复制和高可用、数据结构的原子性操作以及分布式锁等多种机制，保证了数据的一致性和可靠性。这些特性使得 Redis 成为一个广泛应用于高性能、高并发场景下的数据存储解决方案。阅读详情

Redis实例发生故障，而Redis使用的RDB机制，事务的原子性还能否得到保证？

干货：[公粽号：堆栈future]

Redis事务

Redis原子性保证

当Redis采用RDB机制保证数据可靠性时，Redis会按照一定的周期执行内存快照。

一个事务在执行过程中，事务操作对数据所做的修改并不会实时地记录到RDB中，而且，Redis也不会创建RDB快照。我们可以根据故障发生的时机以及RDB是否生成，分成三种情况来讨论事务的原子性保证。

假设事务在执行到一半时，实例发生了故障，在这种情况下，上一次RDB快照中不会包含事务所做的修改，而下一次RDB快照还没有执行。所以，实例恢复后，事务修改的数据会丢失，事务的原子性能得到保证。
假设事务执行完成后，RDB快照已经生成了，如果实例发生了故障，事务修改的数据可以从RDB中恢复，事务的原子性也就得到了保证。
假设事务执行已经完成，但是RDB快照还没有生成，如果实例发生了故障，那么，事务修改的数据就会全部丢失，也就谈不上原子性了。

Redis的事务到底是什么？Redis提供了MULTI、EXEC两个命令来完成这三个步骤。下面我们来分析下。

第一步，客户端要使用一个命令显式地表示一个事务的开启。在Redis中，这个命令就是MULTI。
第二步，客户端把事务中本身要执行的具体操作（例如增删改数据）发送给服务器端。这些操作就是Redis本身提供的数据读写命令，例如GET、SET等。不过，这些命令虽然被客户端发送到了服务器端，但Redis实例只是把这些命令暂存到一个命令队列中，并不会立即执行。
第三步，客户端向服务器端发送提交事务的命令，让数据库实际执行第二步中发送的具体操作。Redis 提供的EXEC命令就是执行事务提交的。当服务器端收到EXEC命令后，才会实际执行命令队列中的所有命令。

了解了Redis的事务之后我们看下它如何满足ACID特性之一：原子性的(A)。

第一种情况是，在执行EXEC命令前，客户端发送的操作命令本身就有错误（比如语法错误，使用了不存在的命令），在命令入队时就被Redis实例判断出来了。等到执行了EXEC命令之后，Redis就会拒绝执行所有提交的命令操作，返回事务失败的结果。这样一来，事务中的所有命令都不会再被执行了，保证了原子性。


#开启事务
127.0.0.1:6379> MULTI
OK
#发送事务中的第一个操作，但是Redis不支持该命令，返回报错信息
127.0.0.1:6379> PUT a:stock 5
(error) ERR unknown command `PUT`, with args beginning with: `a:stock`, `5`, 
#发送事务中的第二个操作，这个操作是正确的命令，Redis把该命令入队
127.0.0.1:6379> DECR b:stock
QUEUED
#实际执行事务，但是之前命令有错误，所以Redis拒绝执行
127.0.0.1:6379> EXEC
(error) EXECABORT Transaction discarded because of previous errors.

第一种情况是，事务操作入队时，命令和操作的数据类型不匹配，但Redis实例没有检查出错误。但是，在执行完EXEC命令以后，Redis实际执行这些事务操作时，就会报错。不过，需要注意的是，虽然Redis 会对错误命令报错，但还是会把正确的命令执行完。在这种情况下，事务的原子性就无法得到保证了。

#开启事务
127.0.0.1:6379> MULTI
OK
#发送事务中的第一个操作，LPOP命令操作的数据类型不匹配，此时并不报错
127.0.0.1:6379> LPOP a:stock
QUEUED
#发送事务中的第二个操作
127.0.0.1:6379> DECR b:stock
QUEUED
#实际执行事务，事务第一个操作执行报错
127.0.0.1:6379> EXEC
1) (error) WRONGTYPE Operation against a key holding the wrong kind of value
2) (integer) 8

最后，我们再来看下第三种情况：在执行事务的EXEC命令时，Redis实例发生了故障，导致事务执行失败。在这种情况下，如果Redis开启了AOF日志，那么，只会有部分的事务操作被记录到AOF日志中。我们需要使用redis-check-aof工具检查AOF日志文件，这个工具可以把未完成的事务操作从AOF文件中去除。这样一来，我们使用AOF恢复实例后，事务操作不会再被执行，从而保证了原子性。当然，如果AOF日志并没有开启，那么实例重启后，数据也都没法恢复了，此时，也就谈不上原子性了。

总结下Redis原子性保证情况如下：