Redis的ACID属性

事务是数据库的一个重要属性，有关事务的4个特性，原子性、一致性、隔离性、持久性，也就是ACID，这些属性既包含了对事务执行结果的要求，也有数据库在事务执行先后的数据状态变化的要求。redis

Redis能够彻底保证ACID属性吗？若是保证不了，在一些场景下数据可能会出错，因此咱们须要了解redis对于这些特性的支持状况shell

事务ACID的要求

原子性

指事务是一个不可分割的工做单位，事务中的操做要么都发生，要么都不发生。数据库

一致性

事务先后数据的完整性必须保持一致。bash

例如：服务器

A有800，B有200，A给B转帐200markdown

操做前A：800，B：200并发

操做后A：600，B：400工具

数据库只有操做先后这两种状态，没有其余中间状态的存在spa

隔离性

事务的隔离性是多个用户并发访问数据库时，数据库为每个用户开启的事务，不能被其余事务的操做数据所干扰，多个并发事务之间要相互隔离。这个会牵扯到数据库的隔离级别，在这边不作详细的介绍，后面会单独出一篇文章介绍线程

持久性

持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即便数据库发生故障也不该该对其有任何影响

Redis的事务实现

事务的执行包含三个步骤，Redis提供了MULTI、EXEC两个命令完成这三个步骤

第一步，客户端要使用一个命令显式地表示一个事务的开启。在 Redis 中，这个命令就是 MULTI。

第二步，客户端把事务中自己要执行的具体操做（例如增删改数据）发送给服务器端。这些操做就是 Redis 自己提供的数据读写命令，例如 GET、SET 等。不过，这些命令虽然被客户端发送到了服务器端，但 Redis 实例只是把这些命令暂存到一个命令队列中，并不会当即执行。

第三步，客户端向服务器端发送提交事务的命令，让数据库实际执行第二步中发送的具体操做。Redis 提供的 EXEX命令就是事务提交的命令。当服务端收到这个命令后，才会实际执行命令队列中的全部命令

下面代码显示了使用命令执行事务的一个过程

#开启事务
127.0.0.1:6379> MULTI
OK
#将a:stock减1，
127.0.0.1:6379> DECR a:stock
QUEUED
#将b:stock减1
127.0.0.1:6379> DECR b:stock
QUEUED
#实际执行事务
127.0.0.1:6379> EXEC
1) (integer) 4
2) (integer) 9
复制代码

咱们假设 a:stock、b:stock 两个键的初始值是 5 和 10。在 MULTI 命令后执行的两个 DECR 命令，是把 a:stock、b:stock 两个键的值分别减 1，它们执行后的返回结果都是 QUEUED，这就表示，这些操做都被暂存到了命令队列，尚未实际执行。等到执行了 EXEC 命令后，能够看到返回了四、9，这就代表，两个 DECR 命令已经成功地执行了。

好了，经过使用 MULTI 和 EXEC 命令，咱们能够实现多个操做的共同执行，可是这符合事务要求的 ACID 属性吗？接下来，咱们就来具体分析下。

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

原子性

主要正对三种异常状况看下

第一种

在执行EXEC命令前，客户端发送操做命令自己存在错误（好比语法错误，使用了不存在的命令），在命令入队时就被 Redis 实例判断出来了。

对于这种状况，在命令入队时，Redis 就会报错而且记录下这个错误。此时，咱们还能继续提交命令操做。等到执行了 EXEC 命令以后，Redis 就会拒绝执行全部提交的命令操做，返回事务失败的结果。这样一来，事务中的全部命令都不会再被执行了，保证了原子性。

#开启事务
127.0.0.1:6379> MULTI
OK
#发送事务中的第一个操做，可是Redis不支持该命令，返回报错信息
127.0.0.1:6379> PUT a:stock 5
(error) ERR unknown command `PUT`, with args beginning with: `a:stock`, `5`, 
#发送事务中的第二个操做，这个操做是正确的命令，Redis把该命令入队
127.0.0.1:6379> DECR b:stock
QUEUED
#实际执行事务，可是以前命令有错误，因此Redis拒绝执行
127.0.0.1:6379> EXEC
(error) EXECABORT Transaction discarded because of previous errors.
复制代码

在这个例子中，事务里包含了一个 Redis 自己就不支持的 PUT 命令，因此，在 PUT 命令入队时，Redis 就报错了。虽然，事务里还有一个正确的 DECR 命令，可是，在最后执行 EXEC 命令后，整个事务被放弃执行了。

第二种

事务在操做入队是，命令和操做的数据类型不匹配。可是，在执行完 EXEC 命令之后，Redis 实际执行这些事务操做时，就会报错。不过，须要注意的是，虽然 Redis 会对错误命令报错，但仍是会把正确的命令执行完。在这种状况下，事务的原子性就没法获得保证了。

#开启事务
127.0.0.1:6379> MULTI
OK
#发送事务中的第一个操做，LPOP命令操做的数据类型不匹配，此时并不报错
127.0.0.1:6379> LPOP a:stock
QUEUED
#发送事务中的第二个操做
127.0.0.1:6379> DECR b:stock
QUEUED
#实际执行事务，事务第一个操做执行报错
127.0.0.1:6379> EXEC
1) (error) WRONGTYPE Operation against a key holding the wrong kind of value
2) (integer) 8
复制代码

看到这里，你可能有个疑问，传统数据库（例如 MySQL）在执行事务时，会提供回滚机制，当事务执行发生错误时，事务中的全部操做都会撤销，已经修改的数据也会被恢复到事务执行前的状态，那么，在刚才的例子中，若是命令实际执行时报错了，是否是能够用回滚机制恢复原来的数据呢？

其实，Redis 中并无提供回滚机制。虽然 Redis 提供了 DISCARD 命令，可是，这个命令只能用来主动放弃事务执行，把暂存的命令队列清空，起不到回滚的效果。

#读取a:stock的值4
127.0.0.1:6379> GET a:stock
"4"
#开启事务
127.0.0.1:6379> MULTI 
OK
#发送事务的第一个操做，对a:stock减1
127.0.0.1:6379> DECR a:stock
QUEUED
#执行DISCARD命令，主动放弃事务
127.0.0.1:6379> DISCARD
OK
#再次读取a:stock的值，值没有被修改
127.0.0.1:6379> GET a:stock
"4"
复制代码

第三种

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

在这种状况下，若是 Redis 开启了 AOF 日志，那么，只会有部分的事务操做被记录到 AOF 日志中。咱们须要使用 redis-check-aof 工具检查 AOF 日志文件，这个工具能够把未完成的事务操做从 AOF 文件中去除。这样一来，咱们使用 AOF 恢复实例后，事务操做不会再被执行，从而保证了原子性。

固然，若是 AOF 日志并无开启，那么实例重启后，数据也都无法恢复了，此时，也就谈不上原子性了。

作个小总结

命令入队时报错，会放弃事务执行，保证原子性
命令入队时正常，执行是报错，不保证原则性
EXEC命令时，实例发生故障，若是开启了AOF日志，能够保证原子性

一致性

和原子性同样也要分三种状况考虑

第一种

命令入队就报错

事务会放弃执行，保证一致性

第二种

命令入队正常，实际执行报错

在这种状况下，有错误的命令不会被执行，正确的命令能够正常执行，也不会改变数据库的一致性。

第三种

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

在这种状况下，实例故障后会进行重启，这就和数据恢复的方式有关了，咱们要根据实例是否开启了 RDB 或 AOF 来分状况讨论下。

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

若是咱们使用了 RDB 快照，由于 RDB 快照不会在事务执行时执行，因此，事务命令操做的结果不会被保存到 RDB 快照中，使用 RDB 快照进行恢复时，数据库里的数据也是一致的。

若是咱们使用了 AOF 日志，而事务操做尚未被记录到 AOF 日志时，实例就发生了故障，那么，使用 AOF 日志恢复的数据库数据是一致的。若是只有部分操做被记录到了 AOF 日志，咱们可使用 redis-check-aof 清除事务中已经完成的操做，数据库恢复后也是一致的。

因此，总结来讲，在命令执行错误或 Redis 发生故障的状况下，Redis 事务机制对一致性属性是有保证的。接下来，咱们再继续分析下隔离性。

隔离性

事务的隔离性保证，会受到和事务一块儿执行的并发操做的影响。而事务执行又能够分红命令入队（EXEC 命令执行前）和命令实际执行（EXEC 命令执行后）两个阶段，因此，咱们就针对这两个阶段，分红两种状况来分析：

一、并发操做在 EXEC 命令前执行，此时，隔离性的保证要使用 WATCH 机制来实现，不然隔离性没法保证；

二、并发操做在 EXEC 命令后执行，此时，隔离性能够保证。

咱们先来看第一种状况。一个事务的 EXEC 命令尚未执行时，事务的命令操做是暂存在命令队列中的。此时，若是有其它的并发操做，咱们就须要看事务是否使用了 WATCH 机制。

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

WATCH 机制的具体实现是由 WATCH 命令实现的，我给你举个例子，你能够看下下面的图，进一步理解下 WATCH 命令的使用。

在 t2 时刻，客户端 X 发送的 EXEC 命令尚未执行，可是客户端 Y 的 DECR 命令就执行了，此时，a:stock 的值会被修改，这就没法保证 X 发起的事务的隔离性了。

刚刚说的是并发操做在 EXEC 命令前执行的状况，下面我再来讲一说第二种状况：兵法操做在EXEC命令以后被服务器接受并执行

由于 Redis 是用单线程执行命令，并且，EXEC 命令执行后，Redis 会保证先把命令队列中的全部命令执行完。因此，在这种状况下，并发操做不会破坏事务的隔离性。

持久性

由于 Redis 是内存数据库，因此，数据是否持久化保存彻底取决于 Redis 的持久化配置模式。

若是 Redis 没有使用 RDB 或 AOF，那么事务的持久化属性确定得不到保证。若是 Redis 使用了 RDB 模式，那么，在一个事务执行后，而下一次的 RDB 快照还未执行前，若是发生了实例宕机，这种状况下，事务修改的数据也是不能保证持久化的。

若是 Redis 采用了 AOF 模式，由于 AOF 模式的三种配置选项 no、everysec 和 always 都会存在数据丢失的状况，因此，事务的持久性属性也仍是得不到保证。

因此，无论 Redis 采用什么持久化模式，事务的持久性属性是得不到保证的。

总结

Redis 经过 MULTI、EXEC、DISCARD 和 WATCH 四个命令来支持事务机制，这 4 个命令的做用，我总结在下面的表中，你能够再看下。

事务的 ACID 属性是咱们使用事务进行正确操做的基本要求。Redis 的事务机制能够保证一致性和隔离性，可是没法保证持久性。不过，由于 Redis 自己是内存数据库，持久性并非一个必须的属性，咱们更加关注的仍是原子性、一致性和隔离性这三个属性。