DK's Notes
zdk
2022-08-03
目录

Redis事务机制

Table of Contents generated with DocToc (opens new window)

# 概述

事务是数据库操作的最小工作单元，由一个有限的数据库操作序列构成。这些操作要么全部执行，要么全部不执行，是一个不可分割的工作单位。 事务在执行时，会提供专门的属性保证：原子性、一致性、隔离性和持久性，也就是ACID属性。这些属性包括了对执行结果的要求，同时也有对数据库在事务执行前后数据状态变化的要求。

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

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

# 事务ACID原则

  • 原子性（Atomicity）：事务作为一个整体被执行，包含在其中的多个的操作要么全部被执行，要么都不执行。这也是业务应用事务时，最被看重的一个属性。
  • 一致性（Consistency）： 就是指数据库中的数据在事务执行前后是一致的。最典型的就是转账的例子。不管用户之间转几次帐，如何转账，事务结束后两个用户钱的总额是不变的。
  • 隔离性（Isolation）：与事务并发直接相关，隔离性是指并发执行的事务之间不能相互影响。简单说，对于任意两个并发的事务 T1 和 T2，在事务 T1 看来，T2 要么在 T1 开始之前就已经结束，要么在 T1 结束之后才开始。这样每个事务都感觉不到有其他事务在并发地执行。
  • 持久性（Durability）：事务一旦提交，所有对数据库数据的修改将永久的保存，即使系统崩溃重启后数据也不会丢失。

# Redis如何实现事务？

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

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

  1. 开启事务：客户端通过MULTI命令，显式地开启一个事务；
  2. 命令入队：客户端把事务中要执行的一系列指令发送给服务器端，如GET、SET 等。需要注意，这些指令只是暂存到命令队列中，并不会立即执行；
  3. 提交事务，执行第二步提交的命令：客户端向服务器端发送提交事务的命令 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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

我们看到执行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>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# EXEC执行后报错

和第一种情况不同的是，命令和操作的数据类型不匹配的错误，在事务操作入队时是检查不出来的。 只能是在执行完 EXEC 命令以后，Redis 实际执行这些事务操作时，会报错。

需要注意的是，虽然 Redis 会对错误命令报错，但还是会把正确的命令执行完，在这种情况下，事务的原子性就无法得到保证了。

命令和操作的数据类型不匹配例子：

#开启事务
127.0.0.1:6379> MULTI
OK
#发送事务中的第一个操作，LPOP命令操作的数据类型不匹配，此时并不报错(a:stock是String类型)
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
1
2
3
4
5
6
7
8
9
10
11
12
13

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

我们可能会想到MySQL中的事务回滚机制，但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
"9"
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# EXEC执行时，Redis发生故障

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

# 总结

  1. 命令入队时就报错，会放弃所有事务执行，保证原子性；
  2. 命令入队时没报错，实际执行时报错，不保证原子性；
  3. 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 命令实现，如下图：

image.png

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

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

image.png

# EXEC执行后

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

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

# 持久性

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

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

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

# 总结

  • Redis 事务支持部分的原子性：如果事务中使用的命令和操作的数据类型不匹配的时候不保证原子性
  • Redis 事务支持一致性
  • Redis 事务支持隔离性
  • Redis 无法保证持久性
在 GitHub 上编辑此页 (opens new window)
#Redis#Redis事务机制
最后更新: 2022/10/04, 8:10:00
Redis高可用-哨兵机制
Redis过期清除策略和内存淘汰机制

← Redis过期清除策略和内存淘汰机制→

Theme by Vdoing | Copyright © 2022-2023 zdk | notes
湘ICP备2022001117号-1
川公网安备 51142102511562号
提供加速服务