参考：

• 31 事务机制：Redis能实现ACID属性吗？| 极客时间 (opens new window)

1. 事务机制：Redis 能实现 ACID 属性吗？

事务提供了对数据读写的 ACID 的保证，那 Redis 可以完全保证 ACID 属性吗？

1.1 ACID 属性的要求

可以参考 事务 这一篇文章。

1.2 Redis 如何实现事务？

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

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

如下代码是使用 MULTI 和 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

好了，通过使用 MULTI 和 EXEC 命令，我们可以实现多个操作的共同执行，但是这符合事务要求的 ACID 属性吗？

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

这里分别分析一下。

1.3.1 原子性

如果事务执行出现错误，原子性还能保证吗？这要分三种情况来看待。

• 第一种情况是，在执行EXEC命令前，客户端发送的操作命令本身就有错误（比如语法错误，使用了不存在的命令），在命令入队时就被 Redis 实例判断出来了。此时 Redis 会拒绝执行所有提交的命令，从而保证了原子性。
• 第二种情况是，某个命令在事务执行期间出现错误，这时尽管 Redis 会对单个命令报错，但还是会把这个事务接下来的所有命令执行完。在这种情况下，事务的原子性就无法得到保证了。
• 第三种情况是，事务执行期间 Redis 实例发生了故障，导致事务执行失败。在这种情况下：
  • 如果Redis开启了AOF日志，那么，只会有部分的事务操作被记录到AOF日志中。我们需要使用redis-check-aof工具检查AOF日志文件，这个工具可以把未完成的事务操作从AOF文件中去除。这样一来，我们使用AOF恢复实例后，事务操作不会再被执行，从而保证了原子性。
  • 如果AOF日志并没有开启，那么实例重启后，数据也都没法恢复了，此时，也就谈不上原子性了。

Redis 也没有提供回滚机制。虽然 Redis 提供了 DISCARD 命令，但这个命令只能用来主动放弃事务的执行，把暂存的命令队列清空，起不到回滚的效果。下面代码展示 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"

这里总结一下 Redis 对事务原子性的保证情况：

• 命令入队时就报错，会放弃事务执行，保证原子性；
• 命令入队时没报错，实际执行时报错，不保证原子性；
• EXEC 命令执行时实例故障，如果开启了 AOF 日志，可以保证原子性。

1.3.2 一致性

我们按照命令出错和实例故障的发生时机，分成三种情况来看：

1. 情况一：命令入队时就报错。在这种情况下，事务本身就会被放弃执行，所以可以保证数据库的一致性。
2. 情况二：命令入队时没报错，实际执行时报错。在这种情况下，有错误的命令不会被执行，正确的命令可以正常执行，也不会改变数据库的一致性。
3. 情况三：EXEC 命令执行时实例发生故障。在这种情况下，实例故障后会进行重启，这就和数据恢复的方式有关了，我们要根据实例是否开启了RDB或AOF来分情况讨论下。
   • 若没有开启 RDB 或 AOF 日志：那实例故障重启后，数据都没有了，数据库是一致的。
   • 若使用了 RDB 快照：因为RDB快照不会在事务执行时执行，所以，事务命令操作的结果不会被保存到 RDB 快照中，使用 RDB 快照进行恢复时，数据库里的数据也是一致的。
   • 若使用了 AOF 日志：
     • 如果事务操作还没有被记录到AOF日志时，实例就发生了故障，那么，使用AOF日志恢复的数据库数据是一致的。
     • 如果只有部分操作被记录到了AOF日志，我们可以使用redis-check-aof清除事务中已经完成的操作，数据库恢复后也是一致的。

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

1.3.3 隔离性

事务的隔离性保证，会受到和事务一起执行的并发操作的影响。而事务执行又可以分成命令入队（EXEC 命令执行前）和命令实际执行（EXEC 命令执行后）两个阶段，所以，我们就针对这两个阶段，分成两种情况来分析：

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

我们先来看第一种情况。一个事务的 EXEC 命令还没有执行时，事务的命令操作是暂存在命令队列中的。此时，如果有其它的并发操作，我们就需要看事务是否使用了 WATCH 机制。

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

WATCH机制的具体实现是由WATCH命令实现的，我给你举个例子，你可以看下下面的图，进一步理解下WATCH命令的使用：

当然，如果没有使用WATCH机制，在EXEC命令前执行的并发操作是会对数据进行读写的。而且，在执行EXEC命令的时候，事务要操作的数据已经改变了，在这种情况下，Redis并没有做到让事务对其它操作隔离，隔离性也就没有得到保障。下面这张图显示了没有WATCH机制时的情况：

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

1.3.4 持久性

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

如果Redis没有使用RDB或AOF，那么事务的持久化属性肯定得不到保证。如果Redis使用了RDB模式，那么，在一个事务执行后，而下一次的RDB快照还未执行前，如果发生了实例宕机，这种情况下，事务修改的数据也是不能保证持久化的。

如果Redis采用了AOF模式，因为AOF模式的三种配置选项no、everysec和always都会存在数据丢失的情况，所以，事务的持久性属性也还是得不到保证。

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

1.4 小结

这一节学习了 Redis 的事务实现，它通过 MULTI、EXEC、DISCARD 和 WATCH 四个命令来支持事务机制，总结如下：

事务的ACID属性是我们使用事务进行正确操作的基本要求。通过这节课的分析，我们了解到了，Redis的事务机制可以保证一致性和隔离性，但是无法保证持久性。不过，因为Redis本身是内存数据库，持久性并不是一个必须的属性，我们更加关注的还是原子性、一致性和隔离性这三个属性。

原子性的情况比较复杂，只有当事务中使用的命令语法有误时，原子性得不到保证，在其它情况下，事务都可以原子性执行。

建议：严格按照 Redis 的命令规范进行程序开发，并且通过 code review 确保命令的正确性。这样一来，Redis 的事务机制就能被应用在实践中，保证多操作的正确执行。