Redis 事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求。

事务的实现

Redis 事务从开始执行到结束通常包含了以下三个阶段：

  • 事务开始
  • 命令入队
  • 事务执行

第一步，客户端使用 MULTI 命令显式地表示一个事务的开启，MULTI 命令可以将执行该命令的客户端从非事务状态切换至事务状态。

第二步，客户端把事务中本身要执行的具体操作（例如增删改数据）发送给服务器端。这些操作就是 Redis 本身提供的数据读写命令，例如 GET、SET 等。不过，这些命令虽然被客户端发送到了服务器端，但 Redis 实例只是把这些命令暂存到一个命令队列中，并不会立即执行，然后向客户端返回 QUEUED 回复。

第三步，客户端向服务器端发送提交事务的 EXEC 命令，让数据库实际执行第二步中发送的具体操作。当服务器端收到 EXEC 命令后才会实际执行命令队列中的所有命令。执行完所有命令后，客户端会回到非事务状态。

  1. #开启事务
  2. 127.0.0.1:6379> MULTI
  3. OK
  5. #将a:stock减1，
  6. 127.0.0.1:6379> DECR a:stock
  7. QUEUED
  9. #将b:stock减1
  10. 127.0.0.1:6379> DECR b:stock
  11. QUEUED
  13. #实际执行事务
  14. 127.0.0.1:6379> EXEC
  15. 1) (integer) 4
  16. 2) (integer) 9

我们假设 a:stock、b:stock 两个键的初始值是 5 和 10。在 MULTI 命令后执行的两个 DECR 命令，是把 a:stock、b:stock 两个键的值分别减 1，它们执行后的返回结果都是 QUEUED，这就表示，这些操作都被暂存到了命令队列，还没有实际执行。等到执行了 EXEC 命令后，可以看到返回了 4、9，这就表明，两个 DECR 命令已经成功地执行了。

Redis 事务的 ACID 特性

1. 原子性

如果事务正常执行，没有发生任何错误，那么，MULTI 和 EXEC 配合使用，就可以保证多个操作都完成。但是，如果事务执行发生错误了，原子性还能保证吗？我们需要分三种情况来看。

第一种情况是，在执行 EXEC 命令前，客户端发送的操作命令本身就有错误（比如语法错误，使用了不存在的命令），在命令入队时就被 Redis 实例判断出来了。对于这种情况，在命令入队时，Redis 就会报错并且记录下这个错误。此时，我们还能继续提交命令操作。等到执行了 EXEC 命令之后，Redis 就会拒绝执行所有提交的命令操作，返回事务失败的结果。这样一来，事务中的所有命令都不会再被执行了，保证了原子性。

  1. #开启事务
  2. 127.0.0.1:6379> MULTI
  3. OK
  5. #发送事务中的第一个操作，但是Redis不支持该命令，返回报错信息
  6. 127.0.0.1:6379> PUT a:stock 5
  7. (error) ERR unknown command `PUT`, with args beginning with: `a:stock`, `5`,
  9. #发送事务中的第二个操作，这个操作是正确的命令，Redis把该命令入队
  10. 127.0.0.1:6379> DECR b:stock
  11. QUEUED
  13. #实际执行事务，但是之前命令有错误，所以Redis拒绝执行
  14. 127.0.0.1:6379> EXEC
  15. (error) EXECABORT Transaction discarded because of previous errors.

第二种情况是，事务操作入队时，命令和操作的数据类型不匹配，但 Redis 实例没有检查出错误。但是，在执行完 EXEC 命令以后，Redis 实际执行这些事务操作时就会报错。不过，需要注意的是，虽然 Redis 会对错误命令报错，但还是会把正确的命令执行完。在这种情况下，事务的原子性就无法得到保证了。

  1. #开启事务
  2. 127.0.0.1:6379> MULTI
  3. OK
  5. #发送事务中的第一个操作，LPOP命令操作的数据类型不匹配，此时并不报错
  6. 127.0.0.1:6379> LPOP a:stock
  7. QUEUED
  9. #发送事务中的第二个操作
  10. 127.0.0.1:6379> DECR b:stock
  11. QUEUED
  13. #实际执行事务，事务第一个操作执行报错，但第二个操作正常执行
  14. 127.0.0.1:6379> EXEC
  15. 1) (error) WRONGTYPE Operation against a key holding the wrong kind of value
  16. 2) (integer) 8

对于这种情况，Redis 中并没有提供回滚机制。虽然 Redis 中提供了 DISCARD 命令，但这个命令只能用来主动放弃事务执行，把暂存的命令队列清空，起不到回滚的效果。DISCARD 命令的使用如下所示：

  2. #读取a:stock的值4
  3. 127.0.0.1:6379> GET a:stock
  4. "4"
  6. #开启事务
  7. 127.0.0.1:6379> MULTI 
  8. OK
  10. #发送事务的第一个操作，对a:stock减1
  11. 127.0.0.1:6379> DECR a:stock
  12. QUEUED
  14. #执行DISCARD命令，主动放弃事务
  15. 127.0.0.1:6379> DISCARD
  16. OK
  18. #再次读取a:stock的值，值没有被修改
  19. 127.0.0.1:6379> GET a:stock
  20. "4"

第三种情况是，在执行事务的 EXEC 命令时，Redis 实例发生了故障，导致事务执行失败。在这种情况下，如果开启了 AOF 日志，那么只会有部分的事务操作被记录到 AOF 日志中。我们需要使用 redis-check-aof 工具检查 AOF 日志文件，这个工具可以把未完成的事务操作从 AOF 文件中去除。这样一来，我们使用 AOF 恢复实例后，事务操作就不会再被执行，从而保证了原子性。当然，如果没有开启 AOF 日志，那么实例重启后，数据也都没法恢复了，此时也就谈不上原子性了。如果使用的是 RDB 机制，由于 RDB 不会在事务执行时执行，所以之后用 RDB 恢复实例数据时，恢复的还是事务之前的数据，这样也相当于保证了原子性。

Redis 为什么不支持事务的回滚？可以参考下官网的解释：https://redis.io/topics/transactions

2. 一致性

事务的一致性保证会受到错误命令、实例故障的影响。所以，我们按照命令出错和实例故障的发生时机，分成三种情况来看。

第一种情况：命令入队时就报错。此时，事务本身就会被放弃执行，所以可以保证数据库的一致性。

第二种情况：命令入队时没报错，实际执行时报错。此时，有错误的命令不会被执行，正确的命令可以正常执行，也不会改变数据库的一致性。

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

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

3. 隔离性

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

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

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

WATCH 命令可以在事务执行前，监控一个或多个键的值变化情况，当事务调用 EXEC 命令执行时，WATCH 机制会先检查监控的键是否被其它客户端修改了。如果修改了就放弃事务执行，避免事务的隔离性被破坏。然后，客户端可以再次执行事务，此时，如果没有并发修改事务数据的操作了，事务就能正常执行，那么隔离性也就得到了保证。
4f8589410f77df16311dd29131676373.webp
当然，如果没有使用 WATCH 机制，在 EXEC 命令前执行的并发操作是会对数据进行读写的。而且，在执行 EXEC 命令时，事务要操作的数据已经改变了，在这种情况下，Redis 并没有做到让事务对其它操作隔离，隔离性也就没有得到保障。

下面我们再来看第二种情况：并发操作在 EXEC 命令之后被服务器端接收并执行。因为 Redis 是用单线程执行命令，而且 EXEC 命令执行后，Redis 会保证先把命令队列中的所有命令执行完。所以，在这种情况下，并发操作不会破坏事务的隔离性，如下图所示：
11a1eff930920a0b423a6e46c23f44ae.webp

4. 持久性

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

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

no-appendfsync-on-rewrite 配置项对持久性的影响：

配置选项 no-appendfsync-on-rewrite 可以配合 appendfsync 选项为 always 或者 everysec 的 AOF 持久化模式使用。当 no-appendfsync-on-rewrite 选项处于打开状态时，在执行 BGSAVE 或 BGREWRITEAOF 命令期间，服务器会暂停对 AOF 文件进行同步，从而尽可能地减少 I/O 阻塞。但这样会导致 always 模式下的 AOF 持久化可能丢失更多的数据。在默认配置下，no-appendfsync-on-rewrite 处于关闭状态。
image.png

配合 Pipeline

Redis 事务在发送每个指令到事务缓存队列时都要经过一次网络读写，当一个事务内部的指令较多时，需要的网络 IO 时间也会线性增长。所以通常 Redis 的客户端在执行事务时都会结合 pipeline 一起使用，这样可以将多次 IO 操作压缩为单次 IO 操作。