面试官：Redis 事务完全保证 ACID 么？

最新推荐文章于 2024-08-21 15:11:19 发布

徐俊生

最新推荐文章于 2024-08-21 15:11:19 发布

阅读量2k

点赞数 2

分类专栏： Redis 文章标签： Redis事务机制 Redis ACID属性

本文链接：https://blog.csdn.net/D812359/article/details/121418946

版权

Redis 专栏收录该内容

12 篇文章 3 订阅

订阅专栏

Redis的事务机制

事务 ACID 属性
Redis 如何实现事务？
Redis 对ACID属性的支持
总结

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

事务在执行时，会提供专门的属性保证：原子性、一致性、隔离性和持久性，也就是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"