Redis的ACID属性

Redis 如何实现事务

Redis 提供了 MULTI、EXEC 两个命令实现事务，MULTI开始一个事务，EXEC是实际执行事务，中间是业务逻辑。

Redis 的事务机制能保证哪些属性

原子性：一个事务中的多个操作必须都完成，或者都不完成。

有以下三种情况：

1. 在执行 EXEC 命令前，客户端发送的操作命令本身就有错误

这种情况，在命令进入队列的时候，就可以判断出来，等到执行EXEC命令的时候，redis会拒绝所有提交的命令操作。

2. 事务操作入队时，命令和操作的数据类型不匹配，但 Redis 实例没有检查出错误。

虽然 Redis 会对错误命令报错，但还是会把正确的命令执行完。在这种情况下，事务的原子性就无法得到保证了。

3. 在执行事务的 EXEC 命令时，Redis 实例发生了故障，导致事务执行失败

如果 Redis 开启了 AOF 日志，那么，只会有部分的事务操作被记录到AOF 日志中。使用 redis-check-aof 工具检查 AOF 日志文件，把已完成的事务操作从 AOF 文件中去除。则使用 AOF 恢复实例后，事务操作不会再被执行，从而保证了原子性。

当然，如果 AOF 日志并没有开启，那么实例重启后，数据也都没法恢复了，此时，也就谈不上原子性了。

 

一致性：数据库中的数据在事务执行前后是一致的

1. 命令入队时就报错

事务本身就会被放弃执行，可以保证数据库的一致性。

2. 命令入队时没报错，实际执行时报错

有错误的命令不会被执行，正确的命令可以正常执行，也不会改变数据库的一致性。

3. EXEC 命令执行时实例发生故障

没有开启 RDB 或 AOF：实例故障重启后，数据都没有了，数据库是一致的。

开启了RDB快照：RDB 快照不会在事务执行时执行，所以，事务命令操作的结果不会被保存到 RDB 快照中，使用 RDB 快照进行恢复时，数据库里的数据也是一致的。

开启了 AOF 日志：当事务操作还没有被记录到 AOF 日志时，实例就发生了故障，那么，使用 AOF 日志恢复的数据库数据是一致的。当只有部分操作被记录到了AOF 日志，使用 redis-check-aof 清除事务中已经完成的操作，数据库恢复后也是一致的。

 

隔离性：数据库在执行一个事务时，其它操作无法存取到正在执行事务访问的数据。

事务执行又可以分成命令入队（EXEC 命令执行前）和命令实际执行（EXEC 命令执行后）两个阶段：

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

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

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

 

持久性

RDB 模式：在一个事务执行后，而下一次的 RDB 快照还未执行前，如果发生了实例宕机，这种情况下，事务修改的数据也是不能保证持久化的。

AOF 模式：三种配置选项 no、everysec 和 always都会存在数据丢失的情况。

所以持久性得不到保证。