redis💡
redis的事务，分为3个步骤。 开启一个事务，然后将命令进行入队，暂时不执行。等运营到exec命令后，在从命令队列中取出命令，进行执行。
- 原子性:(不保证原子性，并且不支持回滚)
- 命令入队时就报错，会放弃事务执行，保证原子性；
- 命令入队时没报错，实际执行时报错，不保证原子性，并不会回滚；
- EXEC 命令执行时实例故障，如果开启了 AOF 日志，重启后，redis-check-aof 工具检查 AOF 日志文件。把未完成的事务操作从 AOF 文件中去除。事务操作不会再被执行。可以保证原子性。但是如果没开启AOF,则不保证原子性
- 一致性(有保证)
- 命令入队时就报错， 未执行命令，保证了一致性
- 命令入队时没报错，实际执行时报错。有错误的命令不会被执行，正确的命令可以正常执行，也不会改变数据库的一致性
- exec执行命令时，实例发送故障。
- 如果没有开启 RDB 或 AOF，那么，实例故障重启后，数据都没有了，数据库是一致的
- 使用了 RDB 快照，因为 RDB 快照不会在事务执行时执行，所以，事务命令操作的结果不会被保存到 RDB 快照中，使用 RDB 快照进行恢复时，数据库里的数据也是一致的
- 使用了 AOF 日志，而事务操作还没有被记录到 AOF 日志时，实例就发生了故障，那么，使用 AOF 日志恢复的数据库数据是一致的。如果只有部分操作被记录到了 AOF 日志，我们可以使用 redis-check-aof 清除事务中已经完成的操作，数据库恢复后也是一致的
- 隔离性(可能无法保证)
- 并发操作在 EXEC 命令前执行，此时，隔离性的保证要使用 WATCH 机制来实现，否则隔离性无法保证；
- 并发操作在 EXEC 命令后执行，此时，隔离性可以保证。
- 持久性(无法保证)
- 如果 Redis 没有使用 RDB 或 AOF，那么事务的持久化属性肯定得不到保证。
- 如果 Redis 使用了 RDB 模式，那么，在一个事务执行后，而下一次的 RDB 快照还未执行前，如果发生了实例宕机，这种情况下，事务修改的数据也是不能保证持久化的。
- 如果 Redis 采用了 AOF 模式，因为 AOF 模式的三种配置选项 no、everysec 和 always 都会存在数据丢失的情况，所以，事务的持久性属性也还是得不到保证
命令
redis为什么事务不支持回滚？
官方文档认为：
- 认为 Redis 事务的执行时，错误通常都是编程错误造成的，这种错误通常只会出现在开发环境中，而很少会在实际的生产环境中出现，所以他认为没有必要为 Redis 开发事务回滚功能；
- 不支持事务回滚是因为这种复杂的功能和 Redis 追求的简单高效的设计主旨不符合。
这里不支持事务回滚，指的是不支持运行时错误的事务回滚。