文章目录

0.前言
- 1.Redis 事务基本流程
1.事务详解
2.总结
3. Redis从入门到精通系列文章

0.前言

Redis 事务是一种将多个命令打包在一起执行的机制，可以保证这些命令的原子性，即要么全部执行成功，要么全部执行失败。Redis 事务采用了乐观锁的方式实现，具体实现原理如下：

开启事务

在客户端执行 MULTI 命令时，Redis 会将该客户端标记为事务状态。此时，客户端发送的所有命令都会被暂存到一个事务队列中，而不是立即执行。

执行事务

在客户端执行 EXEC 命令时，Redis 会将客户端状态从事务状态中移除，并依次执行事务队列中的所有命令。在执行期间，Redis 会将事务队列中的命令全部执行完毕，而不会中途中断。如果在执行期间有任何错误发生，Redis 会将错误信息返回给客户端，同时回滚事务。

回滚事务

如果在执行事务期间发生错误，Redis 会将错误信息返回给客户端，并回滚事务。回滚事务的方式是将客户端之前执行的所有写命令全部撤销，恢复到事务开始之前的状态。

Redis 的事务并不是真正的原子操作，因为事务队列中的命令在执行期间并没有被锁定。如果多个客户端同时执行事务，并且这些事务涉及相同的关键数据，那么就有可能出现数据竞争的情况，从而导致数据不一致。因此，在实际应用中，需要根据具体业务需求进行评估和选择。
Redis 通过 MULTI 、 DISCARD 、 EXEC 和 WATCH 四个命令来实现事务功能，本章首先讨论使用 MULTI 、 DISCARD 和 EXEC 三个命令实现的一般事务，然后再来讨论带有 WATCH 的事务的实现。

1.Redis 事务基本流程

Redis 事务是一组命令的集合，这些命令会被作为一个整体执行。事务中的所有命令要么全部执行，要么全部不执行，这样可以保证事务的原子性。在执行事务期间，其他客户端发送的命令不会被执行，这样可以保证事务的隔离性。

1.事务详解

1.1. 开始事务

使用 MULTI 命令可以开始一个事务。该命令会将客户端的状态从非事务状态切换为事务状态。
使用 MULTI 命令可以开始一个事务：

127.0.0.1:6379> MULTI
OK

1.2. 命令入队

在事务状态下，客户端发送的所有命令都不会立即执行，而是先被放入一个队列中，等到 EXEC 命令被调用时，所有命令会被依次执行。

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET key1 value1
QUEUED
127.0.0.1:6379> INCR key2
QUEUED
127.0.0.1:6379> MGET key1 key2
QUEUED

1.3. 执行事务

使用 EXEC 命令可以执行事务中的所有命令。如果事务中的任何一个命令执行失败，整个事务会被回滚。

127.0.0.1:6379> EXEC
1) OK
2) (integer) 1
3) 1) "value1"
   2) "1"

##1.4. 在事务和非事务状态下执行命令

在事务状态下，客户端发送的所有命令都不会立即执行，而是被放入队列中。在非事务状态下，发送的命令会立即执行。

127.0.0.1:6379> SET key1 value1
OK

##1.5. 事务状态下的 DISCARD 、 MULTI 和 WATCH 命令

DISCARD 命令：用于取消事务，清空事务队列。
MULTI 命令：用于开始一个事务。
WATCH 命令：用于监视一个或多个键，如果这些键在事务执行之前被其他客户端修改，事务会被回滚。

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET key1 value1
QUEUED
127.0.0.1:6379> DISCARD
OK

MULTI 命令：用于开始一个事务。

127.0.0.1:6379> MULTI
OK

WATCH 命令：用于监视一个或多个键，如果这些键在事务执行之前被其他客户端修改，事务会被回滚。

127.0.0.1:6379> WATCH key1
OK

1.6. 带 WATCH 的事务

带 WATCH 的事务可以保证事务执行期间，监视的键不会被其他客户端修改。如果任何一个监视的键被其他客户端修改，事务会被回滚。在 WATCH 命令和 EXEC 命令之间，客户端可以向监视的键发送任意数量的命令，这些命令会被入队，但不会立即执行。

127.0.0.1:6379> WATCH key1
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET key1 value1
QUEUED
127.0.0.1:6379> EXEC
(nil)

1.7. WATCH 命令的实现

Redis 中的 WATCH 命令使用乐观锁实现。在执行事务之前，Redis 会记录监视的键的值，当事务执行时，Redis 会再次检查这些键的值是否发生变化。如果变化了，事务就会被回滚。。

1.8. WATCH 的触发

当执行 EXEC 命令时，Redis 会检查所有监视的键是否发生变化。如果没有变化，事务会继续执行。如果发生变化，事务会被回滚

1.9. 事务的 ACID 性质

Redis 事务具有 ACID 性质，即原子性、一致性、隔离性和持久性。

原子性（Atomicity）：事务中的所有命令要么全部执行，要么全部不执行，这样可以保证事务的原子性。
一致性（Consistency）：事务执行前后，数据库的数据应该保持一致，即事务执行前后的数据状态应该满足一定的约束关系。
隔离性（Isolation）：在事务执行期间，其他客户端发送的命令不会被执行，这样可以保证事务的隔离性。
持久性（Durability）：事务执行完成后，数据应该持久化到磁盘中，这样可以保证事务的持久性。

下面是一个包含 WATCH 命令的事务示例：

127.0.0.1:6379> SET key1 10
OK
127.0.0.1:6379> SET key2 5
OK
127.0.0.1:6379> WATCH key1 key2
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> DECR key1
QUEUED
127.0.0.1:6379> INCR key2
QUEUED
127.0.0.1:6379> EXEC
(nil)

在这个例子中，首先设置了 key1 和 key2 的值。接下来，使用 WATCH 命令监视 key1 和 key2。然后，使用 MULTI 命令开始一个事务，将对 key1 和 key2 的操作入队。在 EXEC 命令执行之前，另一个客户端修改了 key2 的值，这导致事务被回滚。

需要注意的是，Redis 事务并不是真正的 ACID 事务，因为 Redis 的事务无法保证隔离性。在一个事务执行期间，其他客户端发送的命令不会被执行，但是如果这些命令是针对已经入队的事务命令所涉及的键，它们仍然会修改这些键的值，并且这些修改可能会影响到事务的执行结果。因此，在使用 Redis 事务时，需要注意这一点
#2.代码实践
我们分别用jedis 和 Spring Boot 实现 redis 事务

1. jedis

（1）pom.xml 文件依赖：

<dependencies>
    <dependency>
        <groupId>redis.clients</groupId>
        <artifactId>jedis</artifactId>
        <version>3.6.0</version>
    </dependency>
</dependencies>

（2）代码示例：

import redis.clients.jedis.Jedis;
import redis.clients.jedis.Transaction;

public class JedisTransactionDemo {
    
    
    public static void main(String[] args) {
    
    
        Jedis jedis = new Jedis("localhost", 6379);
        Transaction transaction = jedis.multi(); // 开启事务
        try {
    
    
            transaction.set("name", "张三");
            transaction.set("age", "18");
            transaction.exec(); // 提交事务
        } catch (Exception e) {
    
    
            transaction.discard(); // 回滚事务
        } finally {
    
    
            jedis.close(); // 关闭连接
        }
    }
}

Spring Boot 实现 redis 事务

（1）pom.xml 文件依赖：

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-redis</artifactId>
    </dependency>
</dependencies>

（2）application.properties 配置：

# Redis 配置
spring.redis.host=localhost
spring.redis.port=6379
spring.redis.database=0

（3）代码示例：

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.core.SessionCallback;
import org.springframework.stereotype.Component;

@Component
public class RedisTransactionDemo {
    
    
    @Autowired
    private RedisTemplate<String, String> redisTemplate;

    public void test() {
    
    
        redisTemplate.execute(new SessionCallback<Object>() {
    
    
            @Override
            public Object execute(RedisOperations ops) throws DataAccessException {
    
    
                ops.multi(); // 开启事务
                try {
    
    
                    ops.opsForValue().set("name", "张三");
                    ops.opsForValue().set("age", "18");
                    ops.exec(); // 提交事务
                } catch (Exception e) {
    
    
                    ops.discard(); // 回滚事务
                }
                return null;
            }
        });
    }
}

以上就是 jedis 和 Spring Boot 实现 redis 事务的示例工程，可以根据实际需求进行修改和调整。

2.总结

2.1. 在事务和非事务状态下

无论在事务状态下，还是在非事务状态下，Redis 命令都由同一个函数执行，所以它们共享很多服务器的一般设置，比如 AOF 的配置、RDB 的配置，以及内存限制，等等。
不过事务中的命令和普通命令在执行上还是有一点区别的，其中最重要的两点是：
非事务状态下的命令以单个命令为单位执行，前一个命令和后一个命令的客户端不一定是同一个；
事务状态则是以一个事务为单位，执行事务队列中的所有命令：除非当前事务执行完毕，否则服务器不会中断事务，也不会执行其他客户端的其他命令。
在非事务状态下，执行命令所得的结果会立即被返回给客户端；
而事务则是将所有命令的结果集合到回复队列，再作为 EXEC 命令的结果返回给客户端。
事务状态下的 DISCARD 、 MULTI 和 WATCH 命令
除了 EXEC 之外，服务器在客户端处于事务状态时，不加入到事务队列而直接执行的另外三个命令是 DISCARD 、 MULTI 和 WATCH 。
DISCARD 命令用于取消一个事务，它清空客户端的整个事务队列，然后将客户端从事务状态调整回非事务状态，最后返回字符串 OK 给客户端，说明事务已被取消。
Redis 的事务是不可嵌套的，当客户端已经处于事务状态，而客户端又再向服务器发送 MULTI 时，服务器只是简单地向客户端发送一个错误，然后继续等待其他命令的入队。MULTI 命令的发送不会造成整个事务失败，也不会修改事务队列中已有的数据。
WATCH 只能在客户端进入事务状态之前执行，在事务状态下发送 WATCH 命令会引发一个错误，但它不会造成整个事务失败，也不会修改事务队列中已有的数据（和前面处理 MULTI 的情况一样）。

2.2. 小结

Redis 事务是一组命令的集合，具有原子性、一致性、隔离性和持久性的 ACID 特性。事务中的所有命令要么全部执行，要么全部不执行，可以保证事务的原子性。在事务执行期间，其他客户端发送的命令不会被执行，可以保证事务的隔离性。在执行事务之前，可以使用 WATCH 命令监视一个或多个键，如果这些键在事务执行之前被其他客户端修改，事务会被回滚。事务的 ACID 性质可以保证数据的一致性和可靠性。

2.3. 为什么Redis 的事务并不是真正的原子操作

学完本章节之后我们尝试回答一下这个问题。
Redis 的事务并不是真正的原子操作，主要有以下几个原因：

Redis 的事务是基于乐观锁实现的，不会对任何关键数据进行加锁。在事务执行期间，如果有其他客户端对同样的关键数据进行了修改，那么事务就有可能无法成功。这种情况下，Redis 会回滚整个事务，并返回错误信息。因此，Redis 的事务并不能像数据库事务那样保证绝对的原子性。
Redis 的事务在执行期间不会对事务队列中的命令进行锁定，而是在执行期间监控关键数据的变化情况。如果在事务执行期间关键数据发生了变化，Redis 会回滚事务，并返回错误信息。但是，如果在事务执行期间发生了网络故障或者客户端崩溃等异常情况，Redis 无法做到回滚事务，从而可能导致数据不一致。

虽然Redis 的事务不是真正的原子操作，但是对于大部分应用场景来说，Redis 的事务已经足够满足业务需求。需要注意的是，在使用Redis 事务时，需要注意事务的正确性和可靠性，避免出现数据不一致的情况。

2.4. 为什么客户端崩溃等异常情况，Redis 无法自动回滚事务

客户端崩溃等异常情况可能会导致 Redis 事务的执行过程中断，从而无法自动回滚事务。具体来说，当客户端执行 MULTI 命令开启事务后，所有的命令并没有立即被执行，而是暂存到一个事务队列中。当客户端执行 EXEC 命令来提交事务时，Redis 会依次执行事务队列中的所有命令。
如果在事务执行期间发生了网络故障或者客户端崩溃等异常情况，Redis 无法自动提交事务，因此也就无法自动回滚事务。在这种情况下，需要手动执行相应的命令来撤销已经执行的命令，从而实现事务回滚。具体来说，可以使用 DISCARD 命令来撤销事务中尚未执行的所有命令，或者使用相反的命令来撤销已经执行的命令。

3. Redis从入门到精通系列文章

Redis 从入门到精通【进阶篇】之Redis事务详解