Redis事务
Redis事务
Redis 提供了 MULTI、EXEC 两个命令来进行事务操作。
- MULTI：表示一个事务的开启，之后客户端发过来的命令都会暂存到一个命令队列中，并不会立即执行。
- EXEC：当服务器端收到 EXEC 命令后，才会实际执行命令队列中的所有命令。
Redis 的事务机制能保证哪些属性？
原子性
没有发生错误：那操作可以保证原子性
执行发生错误：需要分3种情况
在执行 EXEC 命令前，客户端发送的操作命令本身就有错误。（例如语法错误等）
此时，我们还能继续提交命令操作。等到执行了 EXEC 命令之后，Redis 就会拒绝执行所有提交的命令操作。
在执行 EXEC 命令前，命令和操作的数据类型不匹配，但 Redis 实例没有检查出错误。
Redis会对错误命令报错，但还是会把正确的命令执行完。在这种情况下，事务的原子性就无法得到保证了。
如果有错误语句可以使用
DISCAR命令来让事务放弃在执行事务的 EXEC 命令时，Redis 实例发生了故障，导致事务执行失败。
如果 Redis 开启了 AOF 日志，使用 redis-check-aof 工具检查 AOF 日志文件，这个工具可以把未完成的事务操作从 AOF 文件中去除。这样可以保证原子性。如果没有则保证不了。
一致性
我们按照命令出错和实例故障的发生时机，分成三种情况来看：
命令入队时就报错
在这种情况下，事务本身就会被放弃执行，所以可以保证数据库的一致性。
命令入队时没报错，实际执行时报错
在这种情况下，有错误的命令不会被执行，正确的命令可以正常执行，也不会改变数据库的一致性。
EXEC 命令执行时实例发生故障
- 如果我们没有开启 RDB 或 AOF，那么，实例故障重启后，数据都没有了，数据库是一致的。
- 如果我们使用了 AOF 日志，而事务操作还没有被记录到 AOF 日志时，实例就发生了故障，那么，使用 AOF 日志恢复的数据库数据是一致的。如果只有部分操作被记录到了 AOF 日志，我们可以使用 redis-check-aof 清除事务中已经完成的操作，数据库恢复后也是一致的。
隔离性
事务执行又可以分成命令入队（EXEC 命令执行前）和命令实际执行（EXEC 命令执行后）两个阶段：
- 并发操作在 EXEC 命令前执行，此时，隔离性的保证要使用 WATCH 机制来实现，否则隔离性无法保证；
- 并发操作在 EXEC 命令后执行，此时，隔离性可以保证。
WATCH 机制的作用是，在事务执行前，监控一个或多个键的值变化情况，当事务调用 EXEC 命令执行时，WATCH 机制会先检查监控的键是否被其它客户端修改了。如果修改了，就放弃事务执行，避免事务的隔离性被破坏。然后，客户端可以再次执行事务，此时，如果没有并发修改事务数据的操作了，事务就能正常执行，隔离性也得到了保证。
持久性
- 如果 Redis 没有使用 RDB 或 AOF，那么事务的持久化属性肯定得不到保证。
- 使用了持久化技术：
- 如果 Redis 使用了 RDB 模式，那么，在一个事务执行后，而下一次的 RDB 快照还未执行前，如果发生了实例宕机，就没法保证持久性。
- 如果 Redis 采用了 AOF 模式，因为 AOF 模式的三种配置选项 no、everysec 和 always 都会存在数据丢失的情况（如果刚执行完一个命令，还没有来得及记日志就宕机了，那么这个命令和相应的数据就有丢失的风险）。
所以，不管 Redis 采用什么持久化模式，事务的持久性属性是得不到保证的。
