[TOC] ## 基础 MULTI、EXEC、DISCARD 和 WATCH 命令是 Redis 实现事务的的基础。 Redis 事务的执行过程包含三个步骤： 1. 开启事务； 2. 命令入队； 3. 执行事务或丢弃； ## 三个重要的保证 **Redis 事务可以一次执行多个命令， 并且带有以下三个重要的保证：** 1. 批量指令在执行 EXEC 命令之前会放入队列暂存； 2. 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行； 3. 事务执行过程中，其他客户端提交的命令不会插入到当前命令执行的序列中。 ## 原子性 >1、EXEC执行前 **事务中的所有命令都不会再被执行了，保证了原子性** 2、EXEC执行后 **Redis 虽然会对错误指令报错，但是事务依然会把正确的命令执行完，这时候事务的原子性就无法保证了！** 3、EXEC执行时 如果 Redis 开启了 AOF 日志，那么，只会有部分的事务操作被记录到 AOF 日志中。 我们需要使用 redis-check-aof 工具检查 AOF 日志文件，这个工具可以把未完成的事务操作从 AOF 文件中去除。 这样一来，我们使用 AOF 恢复实例后，事务操作不会再被执行，从而保证了原子性。 **简单总结**： * 命令入队时就报错，会放弃事务执行，保证原子性； * 命令入队时没报错，实际执行时报错，不保证原子性； * EXEC 命令执行时实例故障，如果开启了 AOF 日志，可以保证原子性。 ## 一致性 >一致性会受到错误命令、实例故障发生时机的影响 1、EXEC执行前 事务会被放弃执行，所以可以保证一致性。 2、EXEC执行后 有错误的命令不会执行，正确的指令可以正常执行，一致性可以保证。 3、EXEC执行时,实列故障 实例故障后会进行重启，这就和数据恢复的方式有关了，我们要根据实例是否开启了 RDB 或 AOF 来分情况讨论下。 (1)如果我们没有开启 RDB 或 AOF，那么，实例故障重启后，数据都没有了，数据库是一致的。 (2)如果我们使用了 RDB 快照，**因为 RDB 快照不会在事务执行时执行。** 所以，**事务命令操作的结果不会被保存到 RDB 快照中**，使用 RDB 快照进行恢复时，数据库里的数据也是一致的。 (3)如果我们使用了 AOF 日志，而事务操作还没有被记录到 AOF 日志时，实例就发生了故障，那么，使用 AOF 日志恢复的数据库数据是一致的。 如果只有部分操作被记录到了 AOF 日志，我们可以使用 redis-check-aof 清除事务中已经完成的操作，数据库恢复后也是一致的。 ## 隔离性 >1. 并发操作在`EXEC`命令前执行，隔离性需要通过`WATCH`机制保证。 WATCH 机制的作用是：在事务执行前，监控一个或多个键的值变化情况，当事务调用 EXEC 命令执行时，WATCH 机制会先检查监控的键是否被其它客户端修改了。**如果修改了，就放弃事务执行，避免事务的隔离性被破坏。** 没有watch时，不能保证 > 2. 并发操作在`EXEC`命令之后，隔离性可以保证。 虽然在没有watch时不能保证，但是Redis 是用单线程执行命令，而且，EXEC 命令执行后，Redis 会保证先把命令队列中的所有命令执行完再执行之后的指令。所以，在这种情况下，并发操作不会破坏事务的隔离性。 ## 持久性 >如果 Redis 没有使用 RDB 或 AOF，那么事务的持久化属性肯定得不到保证。 如果 Redis 使用了 RDB 模式，那么，在一个事务执行后，而下一次的 RDB 快照还未执行前，如果发生了实例宕机，数据丢失，这种情况下，事务修改的数据也是不能保证持久化的。 如果 Redis 采用了 AOF 模式，因为 AOF 模式的三种配置选项 no、everysec 和 always 都会存在数据丢失的情况。 所以，事务的持久性属性也还是得不到保证。 **不管 Redis 采用什么持久化模式，事务的持久性属性是得不到保证的。** ## 总结 * Redis 具备了一定的原子性，但不支持回滚。 * Redis 具备 ACID 中一致性的概念。 * Redis 具备隔离性。 * Redis 无法保证持久性。 **Redis 的事务机制可以保证一致性和隔离性，但是无法保证持久性。** 不过，因为 Redis 本身是内存数据库，持久性并不是一个必须的属性，我们更加关注的还是原子性、一致性和隔离性这三个属性。 原子性的情况比较复杂，**当事务中使用的命令语法有误时，原子性得不到保证**，在其它情况下，事务都可以原子性执行。 数据来源：https://mp.weixin.qq.com/s/UZTMuf2UOJu7N4lYQ_AjKQ