Redis事务

一个事务从开始到执行会经历以下三个阶段：

1. 开始事务。

2. 命令入队。

3. 执行事务。

MULTI 命令的执行标记着事务的开始

      这个命令唯一做的就是，将客户端的REDIS_MULTI 选项打开，让客户端从非事务状态切换到事务状态。当客户端进入事务状态之后，客户端发送的命令就会被放进事务队列里。

       但其实并不是所有的命令都会被放进事务队列，其中的例外就是EXEC 、DISCARD 、MULTI和WATCH 这四个命令——当这四个命令从客户端发送到服务器时，它们会像客户端处于非事务状态一样，直接被服务器执行，如下图所示：

redis事务执行流程

对于以下事务队列：

事务入队流程

        程序会首先执行SET 命令，然后执行GET 命令，再然后执行SADD 命令，最后执行SMEMBERS命令。执行事务中的命令所得的结果会以FIFO 的顺序保存到一个回复队列中。

事务状态下的DISCARD 、MULTI 和WATCH 命令

         DISCARD 命令用于取消一个事务，它清空客户端的整个事务队列，然后将客户端从事务状态调整回非事务状态。

         WATCH 命令用于在事务开始之前监视任意数量的键：当调用EXEC 命令执行事务时，如果任意一个被监视的键已经被其他客户端修改了，那么整个事务不再执行，直接返回失败。

以下执行序列展示了上面的例子是如何失败的：

watch监控

       在时间T4 ，客户端B 修改了name 键的值，当客户端A 在T5 执行EXEC 时，Redis 会发现name 这个被监视的键已经被修改，因此客户端A 的事务不会被执行，而是直接返回失败。

WATCH 命令的实现

      在每个代表数据库的redis.h/redisDb 结构类型中，都保存了一个watched_keys 字典，字典的键是这个数据库被监视的键，也就是说watch监控事务中的key。如果这个被监视的key被改动，那么会将这个key的客户端的REDIS_DIRTY_CAS打开，如图：

watch标记

  当客户端发送EXEC 命令、触发事务执行时，服务器会对客户端的状态进行检查：

       如果客户端的REDIS_DIRTY_CAS 选项已经被打开，那么说明被客户端监视的键至少有一个已经被修改了，事务的安全性已经被破坏。服务器会放弃执行这个事务，直接向客户端返回空回复，表示事务执行失败。

      如果REDIS_DIRTY_CAS 选项没有被打开，那么说明所有监视键都安全，服务器正式执行事务。

事务的ACID 性质

       单个Redis 命令的执行是原子性的，但Redis 没有在事务上增加任何维持原子性的机制，所以Redis 事务的执行并不是原子性的。                                                                                                          如果一个事务队列中的所有命令都被成功地执行，那么称这个事务执行成功。                                    另一方面，如果Redis 服务器进程在执行事务的过程中被停止——比如接到KILL 信号、宿主机器停机，等等，那么事务执行失败。                                                                                                           当事务失败时，Redis 也不会进行任何的重试或者回滚动作。

一致性（Consistency）

Redis 的一致性问题可以分为三部分来讨论：入队错误、执行错误、Redis 进程被终结。                 

入队错误

在命令入队的过程中， 如果客户端向服务器发送了错误的命令， 比如命令的参数数量不对，等等，那么服务器将向客户端返回一个出错信息，并且将客户端的事务状态设为REDIS_DIRTY_EXEC 。

       当客户端执行EXEC 命令时，Redis 会拒绝执行状态为REDIS_DIRTY_EXEC 的事务，并返回失败信息。

redis 127.0.0.1:6379> MULTI                                                                                                                                                 OK                                                                                                                redis 127.0.0.1:6379> set key                                                                                                              (error) ERR wrong number of arguments for 'set' command                                                              redis 127.0.0.1:6379> EXISTS key                                                                                                                                         QUEUED                                                                                                            redis 127.0.0.1:6379> EXEC                                                                                                      (error) EXECABORT Transaction discarded because of previous errors.

因此，带有不正确入队命令的事务不会被执行，也不会影响数据库的一致性。

执行错误

      如果命令在事务执行的过程中发生错误，比如说，对一个不同类型的key 执行了错误的操作。          那么Redis 只会将错误包含在事务的结果中，这不会引起事务中断或整个失败，不会影响已执行事务命令的结果，也不会影响后面要执行的事务命令，所以它对事务的一致性也没有影响。

Redis 进程被终结                                                                                                                                         如果Redis 没有采取任何持久化机制，那么重启之后的数据库总是空白的，如果有使用rdb或者aof，那么在此启动会还原数据。

隔离性（Isolation）                                                                                                                                       Redis在执行事务时，不会对事务进行中断，事务可以运行直到执行完所有事务队列中的命令为止。因此，Redis 的事务是总是带有隔离性的。

持久性（Durability）                                                                                                                                     事务的持久性由Redis 所使用的持久化模式决定。

参考资料：《Redis的设计与实现》