redis如何实现事务
事务的执行包含三个步骤，redis提供multi、exec两个命令来完成这三个步骤。
第一步：客户端要使用一个命令显示的表示一个事务的开启。在redis中这个命令就是multi。
第二步：客户端把事务中本身要执行的具体操作(例如增删改查)发送给服务器端。这些操作就是redis本身提供的数据读写命令，例如GET、SET等。这些命令虽然被客户端发送到了服务器端，但redis实例只是把这些命令暂存到一个命令队列中，并不会立即执行。
第三步：客户端向服务器端发送提交事务的命令，让数据库实际执行第二步中发送的具体操作。redis提供的exec就是执行事务提交的。当服务器收到exec命令后，才会实际执行队列中的命令。
#开启事务
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命令后，可以看到返回结果4和9，这就表明，两个decr命令成功执行了。
redis的事务机制能保证ACID吗？
原子性
如果事务正常执行，没有发生任何错误，那么，multi和exec配合使用，就可以保证多个操作都完成。但是，如果事务执行发生错误了，原子性还能保证吗？我们需要分三种情况来看。
第一种情况是，在执行exec命令前，客户端发送的操作命令本身就有错误(比如语法错误，使用了不存在的命令)，在命令入队时就会被检测出来。对于这种情况，在命令入队时，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命令后，整个事务被放弃执行了。
第二种情况。
和第一种情况不同的是，事务操作入队时，命令和操作的数据类型不匹配，但redis实例没有检查出错误。但是，在执行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
事务中的LPOP命令对String类型数据进行操作，入队时没有报错，但是，在exec执行时报错了。lpop命令本身没有执行成功，但事务中的decr命令却成功执行了。
redis不像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"
这个例子中，a:stock键的值一开始为4，然后，执行一个事务，相对a:stock的值-1.但是，在事务的最后，执行了discard命令，所以事务就被放弃了，再次查看a:stock的值，会发现仍然是4。
最后，再来看看第三种情况：在执行事务的exec命令时，redis发生了故障，导致事务执行失败
这种情况下，如果redis开启了AOF日志，那么，只会有部分事务操作被记录到AOF日志中。可以使用redis-check-aof工具检查AOF日志文件，这个工具可以把未完成的事务操作从AOF文件中删除。这样一来，使用AOF恢复数据库实例后，事务操作不会再被执行，从而保证原子性。
当然，如果AOF日志并没有开启，那么实例重启后，数据也就没办法恢复了，此时，就谈不上原子性了。
总结：
- 命令入队就报错，会放弃事务执行，保证原子性
- 命令入队不报错，实际执行时报错，不保证原子性
- exec命令执行时实例故障，如果开启了AOF日志，那么保证原子性。
一致性
事务的一致性保证会受到错误命令、实例故障的影响。所以，我们按照命令出错和实例故障的发生时机，分成三种情况来看。
情况一：命令入队时就报错
在这种情况下，事务本身就会被放弃执行，所以可以保证数据库的一致性。
情况二：命令入队时没报错，实际执行时报错
在这种情况下，有错误的命令不会被执行，正确的命令可以正常执行，也不会改变数据库的一致性。
情况三：EXEC命令执行时实例发生故障
如果我们没有开启RDB或AOF，那么，实例故障重启后，数据都没有了，数据库是一致的。
如果我们使用了RDB快照，因为RDB快照不会在事务执行时执行，所以，事务命令操作的结果不会被保存到RDB快照中，使用RDB快照进行恢复时，数据库里的数据也是一致的。
如果我们使用了AOF日志，而事务操作还没有被记录到AOF日志时，实例就发生了故障，那么，使用AOF日志恢复的数据库数据是一致的。如果只有部分操作被记录到了AOF日志，我们可以使用redis-check-aof清除事务中已经完成的操作，数据库恢复后也是一致的。
所以，总结来说，在命令执行错误或Redis发生故障的情况下，Redis事务机制对一致性属性是有保证的
隔离性
redis单线程执行，不会存在隔离性问题。
持久性
因为Redis是内存数据库，所以，数据是否持久化保存完全取决于Redis的持久化配置模式。
如果Redis没有使用RDB或AOF，那么事务的持久化属性肯定得不到保证。
如果Redis使用了RDB模式，那么，在一个事务执行后，而下一次的RDB快照还未执行前，如果发生了实例宕机，这种情况下，事务修改的数据也是不能保证持久化的。
如果Redis采用了AOF模式，因为AOF模式的三种配置选项no、everysec和always都会存在数据丢失的情况，所以，事务的持久性属性也还是得不到保证。
所以，不管Redis采用什么持久化模式，事务的持久性属性是得不到保证的。