redis中有关事务的特性

事务的四个特性：

ACID:
原子性：一个事务中的多个操作要么都完成，要么都不完成。
一致性：数据库中的数据在事务执行前后是一致的。
隔离性：要求数据库在执行一个事务时，其它操作无法存取到正在执行事务访问的数据
持久性：数据库执行事务后，数据的修改要被持久化保存下来

redis如何实现事务

1：客户端开启事务命令：multi
2：客户端把事务中本身要执行的具体操作（例如增删改数据）发送给服务器端。Redis 实例把这些命令暂存到一个命令队列中，并不会立即执行。
3：客户端向服务器端发送提交事务的命令，让数据库实际执行第二步中发送的具体操作。Redis 提供了EXEC 命令执行事务提交，当服务器端收到 EXEC 命令后，才会实际执行命令队列中的所有命令。

redis的事务机制能否保证ACID

原子性：

事务根据multi与exec配合使用，MULTI 和 EXEC 配合使用，就可以保证多个操作都完成。
但是如果事务执行过程出现错误了错误，redis会怎么处理：
1：在执行 EXEC 命令前，客户端发送的操作命令本身就有错误（比如语法错误，使用了不存在的命令），这时在命令入队时就被 Redis 实例判断出来了。redis会在客户端发送exec命令后，Redis 就会拒绝执行所有提交的命令操作，返回事务失败的结果。这样一来，事务中的所有命令都不会再被执行了，保证了原子性。
2：事务操作入队时，命令和操作的数据类型不匹配，但 Redis 实例没有检查出错误。在执行完 EXEC 命令以后，Redis 实际执行这些事务操作时，就会报错。Redis 会对错误命令报错，但还是会把正确的命令执行完。在这种情况下，事务的原子性就无法得到保证了。redis没有提供回滚机制，但是 Redis 提供了 DISCARD 命令，但是，这个命令只能用来主动放弃事务执行，把暂存的命令队列清空，起不到回滚的效果（即该命令只有在执行exec命令前有效）。
3：在执行事务的 EXEC 命令时，Redis 实例发生了故障，导致事务执行失败。在这种情况下，如果redis实例，开启了 AOF 日志，只会有部分的事务操作被记录到 AOF 日志中。此时需要使用 redis-check-aof 工具检查 AOF 日志文件，这个工具可以把未完成的事务操作从 AOF 文件中去除。这样一的话，使用 AOF 恢复实例后，事务操作不会再被执行，从而保证了原子性。如果没有开启aof，那么就无法保证原子性。

一致性

1：命令入队时报错：
在这种情况下，事务本身就会被放弃执行，所以可以保证数据库的一致性。
2：命令入队时没报错，实际执行时报错
有错误的命令不会被执行，正确的命令可以正常执行，也不会改变数据库的一致性。
3：EXEC 命令执行时实例发生故障
这种情况下，需要考虑redis是否开启了持久化策略，如果没有开启rdb与aof，实例故障重启后，数据都没有了，数据库是一致的。
使用了 AOF 日志，
事务操作没有记录到AOF日志时：实例就发生了故障，那么，使用 AOF 日志恢复的数据库数据是一致的。
部分操作被记录到了AOF日志时：可以使用 redis-check-aof 清除事务中已经完成的操作，数据库恢复后也是一致的。

隔离性

事务的隔离性保证，会受到和事务一起执行的并发操作的影响，事务执行又可以分成（EXEC 命令执行前）和（EXEC 命令执行后）两个阶段

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

持久性

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