请你谈谈对Redis事务的理解

先扯事务是啥-What

是对数据进行读写的一系列操作，要么都成功要么都不成功。
满足以下要求：
原子性。原子性的要求很明确，就是一个事务中的多个操作必须都完成，或者都不完成。
一致性。就是指数据库中的数据在事务执行前后是一致的。
隔离性。它要求数据库在执行一个事务时，其它操作无法存取到正在执行事务访问的数据。
持久性。数据库执行事务后，数据的修改要被持久化保存下来。当数据库重启后，数据的值需要是被修改后的值。

再谈Redis 是如何实现事务-How

第一步，客户端要使用MULTI命令显式地表示一个事务的开启。
第二步，客户端把事务中本身要执行的具体操作（例如增删改数据）发送给服务器端。发送到了服务器端，Redis 实例只是把这些命令暂存到一个命令队列中，并不会立即执行。
第三步，客户端用Redis 提供的 EXEC 命令执行事务提交。当服务器端收到 EXEC 命令后，才会实际执行命令队列中的所有命令。

再谈对于事务的需求来说实现得咋样呢

原子性：

命令入队时就报错，会放弃事务执行，保证原子性；
命令入队时没报错，实际执行时报错，不保证原子性；
EXEC 命令执行时实例故障，如果开启了 AOF 日志，可以保证原子性。

第一种情况是，在执行 EXEC 命令前，客户端发送的操作命令本身就有错误，在命令入队时就被 Redis 实例判断出来了。提交时Redis会拒绝执行。能保证。

第二种情况。事务操作入队时，命令有问题，但 Redis 实例没有检查出错误。但是，在执行完 EXEC 命令以后，Redis 实际执行这些事务操作时，就会报错。但还是会把正确的命令执行完。原子性就无法得到保证了。
（Redis 中并没有提供回滚机制。）

第三种情况：在执行事务的 EXEC 命令时，Redis 实例发生了故障，导致事务执行失败。如果开启了 AOF 日志，那么只会有部分的事务操作被记录到 AOF 日志中。使用 redis-check-aof 工具检查 AOF 日志文件，把未完成的事务操作从 AOF 文件中去除，从而保证了原子性。没开AOF就不保证。

一致性：
情况一：命令入队时就报错，不执行，保证。
情况二：命令入队时没报错，实际执行时报错，正确执行，错误不执行，保证。
情况三：EXEC 命令执行时实例发生故障，没开RDB和AOF数据为空保证，只开RDB不会在事务时执行快照保证，只开AOF是可以删的保证。

隔离性：
两种情况：

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

WATCH 机制的作用是，在事务执行前，监控一个或多个键的值变化情况，当事务调用 EXEC 命令执行时，WATCH 机制会先检查监控的键是否被其它客户端修改了。如果修改了，就放弃事务执行，避免事务的隔离性被破坏。然后，客户端可以再次执行事务，此时，如果没有并发修改事务数据的操作了，事务就能正常执行，隔离性也得到了保证。

并发操作在 EXEC 命令后执行，此时，隔离性可以保证。

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

持久性：
就得扯aof和rdb了

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

Redis 通过 MULTI、EXEC、DISCARD 和 WATCH 四个命令来支持事务机制
在这里插入图片描述
Redis 的事务机制可以保证一致性和隔离性，但是无法保证持久性。不过，因为 Redis 本身是内存数据库，持久性并不是一个必须的属性，我们更加关注的还是原子性、一致性和隔离性这三个属性。原子性的情况比较复杂，只有当事务中使用的命令语法有误时，原子性得不到保证，在其它情况下，事务都可以原子性执行。