31 | 事务机制：Redis能实现ACID属性吗？

---

Redis核心技术与实战

实践篇

31 | 事务机制：Redis能实现ACID属性吗？

事务是指对数据进行读写的一系列操作。事务在执行时，会提供 ACID 属性保证，即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。

Redis 如何实现事务？

事务的执行过程包含三个步骤，Redis 提供了 MULTI、EXEC 两个命令来完成这三个步骤。

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

#开启事务
127.0.0.1:6379> MULTI
OK
#将a:stock减1，
127.0.0.1:6379> DECR a:stock
QUEUED
#将b:stock减1
127.0.0.1:6379> DECR b:stock
QUEUED
#实际执行事务
127.0.0.1:6379> EXEC
1) (integer) 4
2) (integer) 9

Redis 的事务机制能保证哪些属性？

原子性

第一种情况：在执行 EXEC 命令前，客户端发送的操作命令本身就有错误（比如语法错误，使用了不存在的命令），在命令入队时就被 Redis 实例判断出来。

对于这种情况，在命令入队时，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

Redis 中并没有提供回滚机制。

虽然 Redis 提供了 DISCARD 命令，但是，这个命令只能用来主动放弃事务执行，把暂存的命令队列清空，起不到回滚的效果。

#读取a:stock的值4
127.0.0.1:6379> GET a:stock
"4"
#开启事务
127.0.0.1:6379> MULTI 
OK
#发送事务的第一个操作，对a:stock减1
127.0.0.1:6379> DECR a:stock
QUEUED
#执行DISCARD命令，主动放弃事务
127.0.0.1:6379> DISCARD
OK
#再次读取a:stock的值，值没有被修改
127.0.0.1:6379> GET a:stock
"4"

第三种情况：在执行事务的 EXEC 命令时，Redis 实例发生了故障，导致事务执行失败。

在这种情况下，如果 Redis 开启了 AOF 日志，那么，只会有部分的事务操作被记录到 AOF 日志中。使用 redis-check-aof 工具 检查 AOF 日志文件，这个工具可以把未完成的事务中的操作从 AOF 文件中去除。因此，在使用 AOF 恢复实例后，事务操作不会再被执行，从而保证了原子性。

127.0.0.1:6379> ./redis-check-aof appendonly.aof

如果 AOF 日志并没有开启，那么实例重启后，数据也都没法恢复，也就谈不上原子性了。

如果开启了 RDB 日志，由于 RDB 不会在事务执行时执行，RDB 文件中不会记录只执行了一部分的结果数据。之后用 RDB 恢复实例数据，恢复的还是事务之前的数据，从而保证了原子性。

一致性

情况一：命令入队时就报错

在这种情况下，事务本身就会被放弃执行，所以可以保证数据库的一致性。

情况二：命令入队时没报错，实际执行时报错

在这种情况下，有错误的命令不会被执行，正确的命令可以正常执行，也不会改变数据库的一致性。

一致性是指系统从一个正确的状态,迁移到另一个正确的状态。而所谓正确的状态就是指当前的状态满足预定的约束就叫做正确的状态。只要没违反规则，就是保证了一致性。 对于 Redis来说，只要这些磁盘文件和内存中的结果保持一致就具有一致性。

情况三：EXEC 命令执行时实例发生故障

• 如果没有开启 RDB 或 AOF，那么，实例故障重启后，数据都没有了，数据库是一致的。
• 如果使用了 RDB 快照，因为 RDB 快照不会在事务执行时执行，所以，事务命令操作的结果不会被保存到 RDB 快照中，使用 RDB 快照进行恢复时，数据库里的数据也是一致的。
• 如果使用了 AOF 日志，而事务操作还没有被记录到 AOF 日志时，实例就发生了故障，那么，使用 AOF 日志恢复的数据库数据是一致的。如果只有部分操作被记录到了 AOF 日志，可以使用 redis-check-aof 清除事务中已经完成的操作，数据库恢复后也是一致的。

在命令执行错误或 Redis 发生故障的情况下，Redis 事务机制对一致性属性是有保证的。

隔离性

事务执行又可以分成命令入队（EXEC 命令执行前）和命令实际执行（EXEC 命令执行后）两个阶段：

• 并发操作在 EXEC 命令前执行，此时，隔离性的保证要使用 WATCH 机制来实现，否则隔离性无法保证；
• 并发操作在 EXEC 命令后执行，此时，隔离性可以保证。

第一种情况：一个事务的 EXEC 命令还没有执行时，事务的命令操作暂存在命令队列中。

WATCH 机制的作用是，在事务执行前，监控一个或多个键的值变化情况，当事务调用 EXEC 命令执行时，WATCH 机制会先检查监控的键是否被其它客户端修改了。如果修改了，就放弃事务执行，避免事务的隔离性被破坏。然后，客户端可以再次执行事务，此时，如果没有并发修改事务数据的操作了，事务就能正常执行，隔离性也得到了保证。

第二种情况：并发操作在 EXEC 命令之后被服务器端接收并执行。

因为 Redis 是用单线程执行命令，而且，EXEC 命令执行后，Redis 会保证先把命令队列中的所有命令执行完。 所以，在这种情况下，并发操作不会破坏事务的隔离性，如下图所示：

持久性

因为 Redis 是内存数据库，所以，数据是否持久化保存完全取决于 Redis 的持久化配置模式。

• 如果 Redis 没有使用 RDB 或 AOF，那么事务的持久化属性肯定得不到保证。
• 如果 Redis 使用了 RDB 模式，那么，在一个事务执行后，而下一次的 RDB 快照还未执行前，如果发生了实例宕机，这种情况下，事务修改的数据也是不能保证持久化的。
• 如果 Redis 采用了 AOF 模式，因为 AOF 模式的三种配置选项 no、everysec 和 always 都会存在数据丢失的情况，所以，事务的持久性属性也还是得不到保证。

不管 Redis 采用什么持久化模式，事务的持久性属性是得不到保证的。