Redis中的事务可以满足ACID属性吗？

Posted 2023-02-19 Java小叮当

前言

事务是数据库操作的最小工作单元，由一个有限的数据库操作序列构成。这些操作要么全部执行，要么全部不执行，是一个不可分割的工作单位。一键获取最先java文档。

事务在执行时，会提供专门的属性保证：原子性、一致性、隔离性和持久性，也就是ACID属性。这些属性包括了对执行结果的要求，同时也有对数据库在事务执行前后数据状态变化的要求。

大家可能会问，既然事务是数据库特有的机制，那么Redis可以完全保证ACID属性吗？如果有些属性在一些场景下不能保证，很可能会造成数据错误，我们又该如何应对呢？

接下来，我们先从 ACID 属性入手，然后再来看 Redis 是如何实现事务的。

事务 ACID 属性

• 原子性（Atomicity）：事务作为一个整体被执行，包含在其中的多个的操作要么全部被执行，要么都不执行。这也是业务应用事务时，最被看重的一个属性。

• 一致性（Consistency）：就是指数据库中的数据在事务执行前后是一致的。最典型的就是转账的例子，不管用户之间转几次帐，如何转账，事务结束后两个用户钱的总额是不变的。

• 隔离性（Isolation）：与事务并发直接相关，隔离性是指并发执行的事务之间不能相互影响。简单说，对于任意两个并发的事务 T1 和 T2，在事务 T1 看来，T2 要么在 T1 开始之前就已经结束，要么在 T1 结束之后才开始。这样每个事务都感觉不到有其他事务在并发地执行。

• 持久性（Durability）：事务一旦提交，所有对数据库数据的修改将永久的保存，即使系统崩溃重启后数据也不会丢失。

了解了 ACID 属性之后，我们接下来看 Redis 是如何实现事务机制的。

Redis 如何实现事务？

Redis提供了MULTI、EXEC、DISCARD和WATCH命令作为实现事务的的基础。

Redis 事务的执行过程包含三个步骤：

• 开启事务：客户端通过MULTI命令，显式地开启一个事务；

• 命令入队：客户端把事务中要执行的一系列指令发送给服务器端，如GET、SET等。需要注意，这些指令只是暂存到命令队列中，并不会立即执行；

• 提交事务，执行第二步提交的命令：客户端向服务器端发送提交事务的命令 EXEC，当服务端收到 EXEC命令后，才会实际执行命令队列中的所有命令。

使用 MULTI和 EXEC执行事务的过程：

#设置a:stock为10
127.0.0.1:6379> SET a:stock 10
OK

#设置b:stock为20
127.0.0.1:6379> SET b:stock 20
OK

#开启事务
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) 9
2) (integer) 19

我们看到执行DECR的时候返回的都是QUEUED，表示这些操作都被暂存到了命令队列，还没有实际执行。

等执行了 EXEC命令，就可以看到具体每个指令的响应数据。

我们看到 Redis 可以实现多个操作共同执行，接下来我们看看 Redis 的事务机制可以支持哪些 ACID 属性。

Redis 对ACID属性的支持

原子性

正常情况下，没有发生任何错误，使用MULTI和EXEC命令，可以保证多个操作的正常执行。但是，如果事务执行发生错误了，还能保证原子性吗？

这里有三种情况，我们依次看下：

• 在执行EXEC命令前，客户端发送的操作命令本身就有错误，比如：语法错误，使用了不存在的命令；

• 执行完 EXEC命令后，Redis 实际执行这些事务操作时报错，比如：命令和操作的数据类型不匹配（对 String 类型 的 value 执行了 List 列表操作）;

• 执行EXEC命令的时候，Redis 实例发生了故障，导致事务执行失败。

EXEC 执行前报错

对于这种情况，在命令入队时，Redis 就会报错并且记录下这个错误。

此时，我们还能继续提交命令操作。等到执行了EXEC命令之后，Redis就会拒绝执行所有提交的命令操作，返回事务失败的结果。这样一来，事务中的所有命令都不会再被执行了，保证了原子性。

我们来看一个因为命令入队时发生错误，导致事务失败的例子。

#开启事务
127.0.0.1:6379> MULTI
OK

#发送事务中的第一个操作，但是Redis不支持该命令，返回报错信息
127.0.0.1:6379> PUT a:stock 1
(error) ERR unknown command 'PUT'

#发送事务中的第二个操作，这个是正确的命令，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.
127.0.0.1:6379>

EXEC 执行后报错

和第一种情况不同的是，命令和操作的数据类型不匹配的错误，在事务操作入队时是检查不出来的。 只能是在执行完 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) 18

上述事务中的LPOP命令对 String 类型数据进行操作，在入队时没有报错，但是，在EXEC执行时报错了。最后，LPOP命令本身没有执行成功，但是事务中的 DECR命令却成功执行了。

看到这，有同学会想，我们的数据库（比如：mysql）在执行事务的时候，如果有一个失败，那么这个事务中的所有操作都会回滚。那 Redis 是不是也可以实现类似的回滚呢？

首先，Redis 中不具备回滚机制的，Redis 提供了一个DISCARD命令，这个命令只能主动的放弃执行事务，把暂存的命令队列清空，起不到回滚的效果。

使用 DISCARD命令实现放弃事务：

#读取a:stock的值9
127.0.0.1:6379> GET a:stock
"9"
#开启事务
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
"8"

EXEC 执行时，Redis 发生故障

在这种情况下，如果 Redis 开启了 AOF 日志，那么，会有部分的事务操作被记录到 AOF 日志中。

我们需要使用redis-check-aof工具检查 AOF 日志文件，这个工具可以把未完成的事务操作从 AOF 文件中去除。

这样一来，我们使用 AOF 恢复实例后，这些事务操作将不会再被执行，从而保证了原子性。

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

下面，我们简单小结下Redis 对原子性的保证情况：

• 命令入队时就报错，会放弃所有事务执行，保证原子性；

• 命令入队时没报错，实际执行时报错，不保证原子性；

• EXEC命令执行时实例故障，如果开启了 AOF 日志，可以保证原子性。

接下来，我们继续学习，对一致性的保证情况。

一致性

同样的，我们逐一按照上述的三种情况，分析一致性。

EXEC 执行前报错

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

EXEC 执行后报错

在这种情况下，由于报错的命令并没有去执行，只是执行了正确的命令。这种情况下，也是可以保证数据库的一致性的。

EXEC 执行时，Redis 发生故障

这种情况下，由于Redis实例故障，所以会有重启，这就和数据恢复的方式有关了。

下面，我们根据 Redis 实例是否开启 RDB 或 AOF 来分情况讨论下。

首先，我们没有开启 RDB 或 AOF，实例重启之后，数据就没有了，此时数据库是一致的。

如果我们用了RDB快照，由于在事务执行的时候，是不会进行 RDB 快照的，所以，如果Redis实例故障，事务操作的命令是不会记录到 RDB 快照的，所以和上面一样，实例重启之后，数据库是一致的。

如果我们使用了 AOF 日志，当事务操作还没有被记录到 AOF 日志时，实例就发生了故障，那么，使用 AOF 日志恢复的数据库数据是一致的。

如果只有部分操作被记录到了 AOF 日志，我们可以使用 redis-check-aof清除事务中已经完成的操作，数据库恢复后也是一致的。

所以，综上，Redis 事务机制对一致性属性是有保证的。

接下来，我们再继续分析隔离性。

隔离性

事务的隔离性，会受到并发操作的影响。在事务执行时，分为命令入队（EXEC命令执行前）和命令实际执行（EXEC命令执行后）两个阶段。

下面，我们就针对这两个阶段，来分析一下。

EXEC 命令执行前

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

WATCH机制的作用是，在事务执行前，监控一个或多个键的值变化情况。

当事务调用 EXEC命令执行时，WATCH机制会先检查监控的键是否被其它客户端修改了。

如果修改了，就放弃事务执行，避免事务的隔离性被破坏。然后，客户端可以再次执行事务，此时，如果没有并发修改事务数据的操作了，事务就能正常执行，隔离性也得到了保证。

WATCH机制是由WATCH命令实现，如下图：

我们看到因为 WATCH机制，最后执行EXEC的时候，发现 a:stock已经被修改了，放弃了事务的执行，这样一来就保证了隔离性。

如果不使用WATCH机制，在最后执行EXEC的时候，不管a:stock是否已经被修改，都不会放弃事务的执行，隔离性也就没有得到保障。
如下图：

上面说的是并发操作在EXEC命令前执行的情况，接下来再来说一说第二种情况：并发操作在 EXEC命令执行之后被服务器端接收并执行。

EXEC 命令执行后

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

最后我们再来分析一下对持久性的保证情况。

持久性

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

如果 Redis 没有使用 RDB 或 AOF，那么事务的持久化属性肯定得不到保证。

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

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

所以，不管Redis采用什么持久化模式，事务的持久性属性是得不到保证的。
想要了解 Redis持久化机制的童鞋可以看我的上篇文章：一文读懂Redis持久化机制

总结

• Redis事务支持部分的原子性：如果事务中使用的命令和操作的数据类型不匹配的时候不保证原子性；

• Redis 事务支持一致性

• Redis 事务支持隔离性

• Redis 无法保证持久性

最后

全面覆盖BATJ等一线互联网公司的面试题及解答，由BAT一线互联网公司大牛带你深度剖析面试题背后的原理，不仅授你以鱼，更授你以渔，为你面试扫除一切障碍。

👇🏻 添加 博主 获取地址👇🏻