Redis（十六）：Redis事务

1. 事务的实现

2. 带WATCH的事务

3. 事务的ACID特性

---

1. 事务的实现

    Redis通过MULTI、EXEC、WATCH等命令来实现事务功能，事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而去执行其它客户端的命令请求。事务的执行分为事务开始、命令入队和事务执行三个阶段。

1.1 事务开始

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

redis> MULTI

1.2 命令入队

    每个redis客户端都有自己的事务状态，这个事务状态保存在客户端状态的master属性里面：

typedef struct redisClient {
    // ...

    // 事务状态
    multiState mstate;

    // ...
};

/*
 * 事务状态
 */
typedef struct multiState {

    // 事务队列，FIFO 顺序
    multiCmd *commands;     /* Array of MULTI commands */

    // 已入队命令计数
    int count;              /* Total number of MULTI commands */
    int minreplicas;        /* MINREPLICAS for synchronous replication */
    time_t minreplicas_timeout; /* MINREPLICAS timeout as unixtime. */
} multiState;

/*
 * 事务命令
 */
typedef struct multiCmd {

    robj **argv; // 参数

    int argc;  // 参数数量

    struct redisCommand *cmd;  // 命令指针

} multiCmd;

    事务状态包含一个事务队列，以及一个已入队命令的计数器，即事务队列的长度，事务队列是一个multiCmd类型的书组，数组中每个multiCmd都保存了一个已入队命令的相关信息。 

    当一个客户端处于非事务状态时，这个客户端的命令会被立即执行，当一个客户端切换到事务状态之后，服务器会根据这个客户端发来的不同命令执行不同的操作：

• 如果客户端发送的命令是EXEC、DISCARD、WATCH、MULTi四个命令的其中一个时，那么服务器立即执行这个命令；
• 如果不是这四个命令，那么服务器会将这个命令放入一个事务队列里面，然后向客户端返回QUEUED；

1.3 事务执行

    当一个处于事务状态的客户端向服务器发送EXEC命令时，这个EXEC命令将立即被服务器执行，服务器会遍历这个客户端的事务队列，执行队列中保存的所有命令，最后将执行结果全部返回给客户端。

2. 带WATCH的事务

    WATCH是一个乐观锁，关于乐观锁和悲观锁的介绍可以参考这篇博客。WATCH可以在EXEC命令执行之前，监视任意数量的数据库键，并在EXEC命令执行时，检查被监视的键是否至少有一个已经被修改过了，如果是的话，服务器将拒绝执行这个事务，并向客户端返回执行失败的空回复。

2.1 WATCH命令的实现

    每个Redis数据库都保存着一个watched_keys的字典，这个字典的键是被某个WATCH命令监视的数据库键，而字典的值是一个链表，链表中记录了所有监视相应数据库键的客户端。

typedef struct redisDb {
    // ...
    
    // 正在被WATCH命令监视的键
    dict *watched_keys;

    // ...
} redisDb;

    通过watched_keys字典，服务器可以清楚地知道哪些数据库键被监视，以及哪些客户端正在监视这些键。 

2.2 监视机制的触发

    所有对数据库进行修改的命令，比如SET、LPUSH、SADD、ZREM、DEL、FLUSHDB等等，在执行完之后，都会调用touchWatchKey函数对watched_keys字典进行检查，查看是否有客户端正在监视刚刚被修改过的数据库键，如果有的话，那么会将监视被修改键的客户端的REDIS_DIRTY_CAS标识打开，表示该客户端的事务安全性已经被破坏。    

2.3 判断事务是否安全

    当服务器收到一个客户端发过来的EXEC命令时，服务器会根据这个客户端是否打开了REDIS_DIRTY_CAS标识来决定是否执行事务：

• 如果REDIS_DIRTY_CAS标识被打开，表示监视的键至少有一个被修改了，此时事务不再安全，服务器拒绝执行客户端的事务；
• 如果REDIS_DIRTY_CAS标识没有被打开，说明监视的键没有被修改，事务仍然是安全的，服务器将执行这个事务；

2.4 WATCH事务

    带WATCH事务的执行过程为：

• redis> WATCH xxx
• redis> MULTI
• redis> CMD1，CMD2，...，CMDN
• redis> EXEC

3. 事务的ACID特性

3.1 原子性（Atomicity）

    对于Redis的事务功能来说，事务队列中的命令要么就全部执行，要么就一个都不执行，因此，redis的事务时具备原子性的。但是Redis的事务和传统关系型数据库的事务最大区别是，Redis不支持事务的回滚机制，即使事务队列中的某个命令在执行期间出现了错误，整个事务也会继续执行下去，直到事务队列中的所有命令执行完毕。

3.2 一致性（Consistency）

    事务具有一致性是指的，如果数据库在执行事务之前是一致的，那么在执行事务之后，无论事务是否成功，数据库也应该是一致的。“一致”指的是数据符合数据库本身的定义和要求，没有包含非法或者无效的错误数据。Redis通过谨慎的错误检测和简单的设计来保证事务的一致性。

• 入队错误：如果一个事务在入队命令过程中，出现了命令不存在，或者命令的格式不正确等情况，那么redis将拒绝执行这个事务；
• 执行错误：即使在事务的执行过程中发生了错误，服务器也不会中断事务的执行，它会继续执行事务中剩下的其它命令，并且已执行的命令不会被出错的命令影响。
• 服务器停机：如果Redis服务器在执行事务的过程中停机，那么根据服务器所使用的持久化模式，无论redis服务器运行在哪种持久化模式下，事务执行中途发生的停机都不会影响数据库的一致性。

3.3 隔离性（Isolation）

    事务的隔离性是指即使数据库中有多个事务并发地执行，各个事务之间也不会互相影响，并且并发状态下执行的事务和串行执行的事务的产生的结果完全相同。因为Redis使用单线程的方式执行事务（即使6.0引入了多单线，但是执行命令时也是主线程串行执行），并且服务器保证在执行事务期间不会对事务进行中断，因此，Redis的事务总是以串行的方式运行的，并且事务也总具有隔离性。

3.4 持久性（Durability）

    事务的持久性是指的当一个事务执行完毕时，执行这个事务的所得结果已经被保存到永久性的存储介质中了，即使服务器在事务执行完毕之后停机，执行事务所得的结果也不会丢失。因为redis的事务是简单的用队列包裹起了一组Redis命令，Redis并没为事务提供任何额外的持久化功能，所以Redis事务的持久性由Redis所使用的持久化模式决定。只有当服务器运行在AOF持久化模式下，并且appendfsync的选项设置为always时，这种配置下事务是具有持久性的，其它配置模式下不具备持久性。