Redis事务

事务的基本属性

• A（atomicity），原子性。
• C（consistency），一致性。
• I（isolation），隔离性。
• D（durability），持久性。

Redis如何实现事务

• 第一步、客户端要使用一个命令显式地表示一个事务的开启。在 Redis 中，这个命令就是 MULTI。
• 第二步、客户端把事务中本身要执行的具体操作（例如增删改数据）发送给服务器端。这些操作就是 Redis 本身提供的数据读写命令，例如 GET、SET 等。
• 不过，这些命令虽然被客户端发送到了服务器端，但 Redis 实例只是把这些命令暂存到一个命令队列中，并不会立即执行
• 第三步、客户端向服务器端发送提交事务的命令，让服务器实际执行第二步中发送的具体操作。Redis 提供的 EXEC 命令就是执行事务提交的。当服务器端收到 EXEC 命令后，才会实际执行命令队列中的所有命令。

原子性

• 情况1、在执行EXEC命令前，客户端发送的操作命令本身有错误，比如语法错误。这种情况，执行EXEC时会拒绝执行所有提交的命令。
• 情况2、提交的操作命令和数据类型不匹配，比如将get用到了hash结构上，redis实例检查不出错误，执行EXEC时，不匹配的命令执行失败，其他正确的命令执行成功，没有保证原子性。
• 情况3、执行EXEC时，redis实例故障了。如果开启了AOF日志、则只有部分事务操作被记录了，需要使用redis-check-aof 工具检查 AOF 日志文件，这个工具可以把未完成的事务操作从 AOF 文件中去除。

一致性

• 情况一：命令入队时就报错在这种情况下，事务本身就会被放弃执行，所以可以保证数据库的一致性。
• 情况二：命令入队时没报错，实际执行时报错在这种情况下，有错误的命令不会被执行，正确的命令可以正常执行，也不会改变数据库的一致性。
• 情况三：EXEC 命令执行时实例发生故障在这种情况下，实例故障后会进行重启，这就和数据恢复的方式有关了。
• 如果没有开启 RDB 或 AOF，那么，实例故障重启后，数据都没有了，数据库是一致的。
• 如果使用了 RDB 快照，因为 RDB 快照不会在事务执行时执行，所以，事务命令操作的结果不会被保存到 RDB 快照中，使用 RDB 快照进行恢复时，数据库里的数据也是一致的。
• 如果使用了 AOF 日志，而事务操作还没有被记录到 AOF 日志时，实例就发生了故障，那么，使用 AOF 日志恢复的数据库数据是一致的。
• 如果只有部分操作被记录到了 AOF 日志，可以使用 redis-check-aof 清除事务中已经完成的操作，数据库恢复后也是一致的。

隔离性

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

持久性

• 因为 Redis 是内存数据库，所以，数据是否持久化保存完全取决于 Redis 的持久化配置模式。
• 如果 Redis 没有使用 RDB 或 AOF，那么事务的持久化属性肯定得不到保证。
• 如果 Redis 使用了 RDB 模式，那么，在一个事务执行后，而下一次的 RDB 快照还未执行前，如果发生了实例宕机，这种情况下，事务修改的数据也是不能保证持久化的。
• 如果 Redis 采用了 AOF 模式，因为 AOF 模式的三种配置选项 no、everysec 和 always 都会存在数据丢失的情况，所以，事务的持久性属性也还是得不到保证。
• 所以，不管 Redis 采用什么持久化模式，事务的持久性属性是得不到保证的