说说 Redis 事务( 三 ) _生活百科

redis-check-aof清除事务中已经完成的操作，数据库恢复后数据也是一致的。

隔离性（I）
1. 并发操作在 EXEC 执行前，隔离性需要通过 WATCH 机制来保证
2. 并发操作在 EXEC 命令之后，隔离性可以保证

情况 a可以参考前面的实例分析 WATCH 命令的使用。情况 b，由于 Redis 是单线程执行命令，EXEC 命令执行后，Redis 会保证先把事务队列中的所有命令执行完之后再执行之后的命令。

持久性（D）

若 Redis 没有开启持久化，那么就是所有数据都存储在内存中，一旦重启，数据就会丢失，因此此时事务的持久性是肯定无法得到保证的。若 Redis 开启了持久化，当实例宕机重启，还是会有可能丢失数据，因此也并能完全保证持久性。因此，我们可以说 Redis 事务无法一定保证持久性，仅在特殊的情况下，可以保证持久性。

关于 Redis 在开启持久化之后，为啥还会丢失数据，笔者会单独整理一篇 Redis 持久化与主从相关的文章来介绍，此处简单说下。如果配置了 RDB 模式，在一个事务执行后，下一次 RDB 快照还未执行前， Redis 实例发生了宕机，数据就会丢失、如果配置了 AOF 模式，而 AOF 模式的三种配置选项 no，everysec，always 也都可能会产生数据丢失的情况。

总结一下，Redis 事务对 ACID 的支持情况：

具备一定的原子性，但不支持回滚
满足一致性
满足隔离性
无法保证持久性

Redis 事务为什么不支持回滚看一下官网的的说明：

What about rollbacks?Redis does not support rollbacks of transactions since supporting rollbacks would have a significant impact on the simplicity and performance of Redis.

文章插图
大部分需要事务回滚的情况是程序错误导致的，这种情况一般是开发环境，生产环境不应该出现这种错误。对于逻辑错误，例如应该加 1，结果写成了加 2，这种情况无法通过回滚来解决。Redis 追求的是简单高效，而传统事务的实现相对复杂很多，这和 Redis 的设计思想是违背的。当我们享受 Redis 的快速时，也就无法再要求它更多。
总结本文主要介绍了 Redis 事务的基础指令与执行流程，并分析了其对传统 ACID 特性支持的情况，相信大家对 Redis 事务已经有了一个简单的了解。通过上面的介绍，会发现 Redis 的事务似乎有点鸡肋，确实实际中也很少会使用。至于事务的具体实现，笔者后续文章会结合源码进行分析。今天的文章就到这里，下期我们接着学。