Redis 事务的实现

目录

1 事务的实现

1.1 事务开始

1.2 命令入队

1.3 事务队列

1.4 执行事务

2 WATCH 命令的实现

2.1 使用 WATCH 命令监视数据库键

2.2 监视机制的触发

2.3 判断事务是否安全

2.4 一个完成的 WATCH 事务执行过程

2.5  取消数据库键的监视

3 事务的 ACID 性质

3.1 原子性

3.2 一致性

3.3 隔离性

3.4 持久性

4 重点总结

---

Redis 通过 MULTI、EXEC、WATCH 等命令来实现事务(transaction)功能。事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求。

以下是一个事务执行的过程，该事务首先以一个 MULTI 命令为开始，接着将多个命令放入事务当中，最有由 EXEC 命令将这个事务提交(commit)给服务器执行：

redis> MULTI
OK
redis> SET "name" "chenxl"
QUEUED
redis> GET "name"
QUEUED
redis> SET "age" 18
QUEUED
redis> GET "age"
QUEUED
redis> EXEC
1) OK
2) "chenxl"
3) OK
4) "18"

---

1 事务的实现

一个事务从开始到结束通常会经历以下三个阶段：

1.事务开始：MULTI

2.命令入队：QUEUED状态

3.事务执行：EXEC

1.1 事务开始

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

redis> MULTI
OK

MULTI 命令可以将执行该命令的客户端从非事务状态切换成事务状态，这个切换是通过在客户端状态的 flags 属性中打开 REDIS_MULTI 标识来完成的。

1.2 命令入队

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

1. 如果客户端发送的命令是 EXEC、DISCARD、WATCH、MULTI 四个命令的其中一个，那么服务器立即执这个命令；
2. 如果客户端发送的命令是 EXEC、DISCARD、WATCH、MULTI 四个命令以外的其他命令，那么服务器并不立即执行这个命令，而是将这个命令放入一个事务队列里，然后向客户端返回 QUEUED 回复。

1.3 事务队列

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

typedef struct redisClient {

    //...

    //事务状态
    multiState mstate;  /* MULTI/EXEC state */

    //...

} redisClient;

事务状态包含一个事务队列，以及一个已入队命令的计数器（也可是说是事务队列的长度）：

typedef struct multiState {

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

    //已入队命令计数
    int count;

} multiState;

事务队列是一个 multiCmd 类型的数组，每个数组中的每个multiCmd 结构都保存了一个已入队命令的相关信息，包括指向命令实现函数的指针、命令的参数，以及参数的数量：

typedef struct multiCmd {
    
    //参数
    robj **argv;

    //参数数量
    int argc;
    
    //命令指针
    struct redisCommand *cmd;
} multiCmd;

事务队列已先进先出（FIFO）的方式保存入队命令，较先入队的命令会被放到数组的前面，而较后入队的命令则会被放到数组的后面。

举个例子，如果客户端执行以下命令：

redis> MULTI
OK

redis> SET "name" "chenxl"
QUEUED

redis> GET "name"
QUEUED

redis> SET "age" 18
QUEUED

redis> GET "age"
QUEUED

那么服务器将为客户端创建如图 1-3-1所示的事务状态：

最先入队的 SET 命令被放在了事务队列的索引 0 位置上；

第二入队的 GET 命令放在了事务队列的索引 1 位置上；

第三入队的另一个 SET 命令被放在了事务队列的索引 2 位置上；

最后入队的另一个 GET 命令被放在事务队列的索引 3 位置上。

1.4 执行事务

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

EXEC 命令的实现原理可以用以下伪代码来描述：

def EXEC():
    # 创建空白的回复队列
    reply_queue = []

    # 遍历事务队列中的每个项
    # 读取命令的参数，参数的个数，以及要执行的命令
    for argv, argc, cmd in client.mstate.commands:

      # 执行命令，并取得命令的返回值
      reply = execute_command(cmd, argv, argc)

      # 将返回值追加到回复队列末尾
      reply_queue.append(reply)

    #移除 REDIS_MULTI 标识，让客户端回到非事务状态
    client.flags & = ~REDIS_MULTI

    # 清空客户端的事务状态，包括：
    # 1)清零入队命令计数器
    # 2)释放事务队列

    client.mstate.count = 0
    release_transaction_queue(client.mstate.commands)

    # 将事务的执行结果返回给客户端
    send_reply_to_client(client, reply_queue)

---

2 WATCH 命令的实现

WATCH 命令是一个乐观锁（optimistic locking），它可以在 EXEC 命令执行之前，监视任意数量的数据库键，并在 EXEC 命令执行时，检查被监视的键是否至少有一个已经被修改过了，如果是的话，服务器将拒绝执行事务，并向客户端返回代表事务执行失败的空回复。

大多数情况下，不同的客户端会访问不同的键，相互同时竞争同一key的情况一般都很少，乐观锁能够以很好的性能解决数据冲突的问题。

表 2-1 展示了一个事务执行失败的例子：

表 2-1 两个客户端执行命令的过程

时间	客户端A	客户端B
T1	WATCH "name"
T2	MULTI
T3	SET "name" "perter"
T4		SET "name" "john"
T5	EXEC

在时间T4，客户端B 修改了 "name" 键的值，当客户端A 在 T5 执行 EXXEC 命令时，服务器发现 WATCH 监视的键 "name" 已经被修改，因此服务器拒绝执行客户端A 的事务，并向客户端A 返回空回复。

下面介绍 WATCH 命令的实现原理，事务是如何监视某个键，并在键被修改的情况下，确保事务的安全性。

2.1 使用 WATCH 命令监视数据库键

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

typedef struct redisDb {


    // ...

    // 正在被 WATCH 命令监视的键
    dict *watched_keys;

    // ...

} redisDb;

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

图 2-1-1 是一个watched_keys 字典的示例，从这个 watched_kyes 字典中可以看出：客户端 c1 和 c2 正在监视键 "name"；客户端 c3 正在监视键 "age"；客户端 c2 和 c4 正在监视键 "address"。

通过执行 WATCH 命令，客户端可以在 watched_keys 字典中与被监视的键进行关联。举个例子，如果客户端为 c10086，那么客户端执行 WATCH "name" "age" 命令之后，watched_keys 字典将被更新至图 2-1-2 所示的状态，其中虚线包围的两个 c10086 节点就是由刚刚执行 WATCH 命令添加到字典中的。

2.2 监视机制的触发

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

touchWatchKey 函数的定义可以用以下伪代码来描述：

def touchWatchKey(db, key):
    
    # 如果键 key 存在于数据库的 watched_keys 字典中
    # 那么说明至少有一个客户端在监视这个 key
    if key in db.watched_keys:
        
        # 遍历所有监视键的客户端
        for client in db.watched_keys[key]:
        
            # 打开标识
            client.flages |= REDIS_DIRTY_CAS

举个例子，对于图 2-2-1 所示的 watched_keys 字典来说：

• 如果键 "name" 被修改，那么 c1、c2、c10086 三个客户端的 REDIS_DIRTY_CAS 标识被打开；
• 如果键 "age" 被修改，那么 c3 和 c10086 两个客户端的 REDIS_DIRTY_CAS 标识被打开；
• 如果键 "address" 被修改，那么 c2 和 c4 两个客户端的 REDIS_DIRTY_CAS 标识被打开。

2.3 判断事务是否安全

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

• 如果客户端的 REDIS_DIRTY_CAS 标识已经被打开，那么说明客户端所监视的键当中，至少有一个键已经被修改过了，在这种情况下，客户端提交的事务已经不再安全，所以服务器会拒绝执行客户端提交的事务；
• 如果 客户端的 REDIS_DIRTY_CAS 标识没有被打开，那么说明客户端监视的所有键都没有被修改过（或者客户端没有监视任何键），事务仍然是安全的，服务器将执行客户端提交的事务。

这个判断是否执行事务的过程可以用流程图 2-3-1 来描述。

举个例子，对于图 2-2-1 所示的 watched_keys字典来说，如果某个客户端对 "name" 键进行了修改（比如执行 SET "name" "john"），那么 c1、c2、c10086 三个客户端的 REDIS_DIRTY_CAS 表示被打开。当这个三个客户端向服务器发送 EXECX 命令时，服务器会拒绝执行它们提交的事务，以此来保证事务的安全性。

2.4 一个完成的 WATCH 事务执行过程

为了进一步熟悉 WATCH 命令的运作方式，让我们来看一个带有 WATCH 的事务从开始到失败的整个过程。

假设当前客户端为 c10086，而数据库 watched_keys 字典的当前状态如图 2-4-1所示，那么当 c10086 执行以下 WATCH 命令之后：

c10086> WATCH "name"
OK

watched_keys 字典将更新至图 2-4-2所示的状态。

接下来，客户端 c10086 继续向服务器发送 MULTI 命令，并将一个 SET 命令放入事务队列：

c10086> MULTI
OK
c10086> SET "name" "peter"
QUEUED

就在这时，另一个客户端 c999 向服务器发送了一条 SET 命令，将 "name" 键的值设置成 "john"：

c999> SET "name" "john"
OK

c999 执行的这个 SET 命令会导致正在监视 "name" 键的所有客户端的 REDIS_DIRTY_CAS 标识被打开，其中包括客户端 c10086。

之后，当 c10086 向服务器发送 EXEC 命令时，因为 c10086 的 REDIS_DIRTY_CAS 标识已经被打开，所以服务器将拒绝执行它提交的事务：

c10086> EXEC
(nil)

2.5  取消数据库键的监视

1. WATCH 命令可以被调用多次。对键的监视从 WATCH 命令执行之后开始生效，直到调用 EXEC 命令为止，不管事务是否成功执行，对所有键的监视都会被取消。
2. 当客户端断开连接时，该客户端对键的监视也会被取消。
3. UNWATCH 命令可以手动取消对所有键的监视。

---

3 事务的 ACID 性质

在传统的关系型数据库中，常常用 ACID 性质来检验事务功能的可靠性和安全性。

在 Redis 中，事务总是具有原子性（Atomicity）、一致性（Consistency）和隔离性（Isolation），并且当 Redis 运行在某种特定的持久化模式下时，事务也具有持久性（Durability）。

3.1 原子性

事务具有原子性指的是，数据库将事务中的多个操作当作一个整理来执行，服务器要么就执行事务中的所有操作，要么就一个操作也不执行。

对于 Redis 的事务功能来说，事务队列中的命令要么全部执行，要么就一个都不执行，因此 Redis 的事务是具有原子性的。

举个例子，下面展示的是一个成功执行的事务，事务中的所有命令都会被执行：

redis> MULTI
OK
redis> SET msg "hello"
QUEUED
redis> GET msg
QUEUED
redis> EXEC
1) OK
2) "hello"

与此相反，以下展示一个执行失败的事务，这个事务因为命令入队列出错而被服务器拒绝执行，事务中的所有命令都不会被执行：

redis> MULTI
OK
redis> SET msg "hello"
QUEUED
redis> GET
(error) ERR wrong number of arguments for 'get' command
redis> GET msg
QUEUED
redis> EXEC
(error) EXECABORT Transaction discarded because of previous errors.

Redis 的事务和传统的关系型数据库事务的最大区别在于，Redis 不支持事务回滚机制（rollback），即使事务队列中的某个命令在执行期间出现了错误，整个事务也会继续执行下去，直到将事务队列中的所有命令都执行完毕为止。

在下面的例子中，即使 RPUSH 命令在执行期间出现了错误，事务的后续命令也会继续执行下去，并且之前执行的命令也不会有任何影响：

redis> SET msg "hello"     # msg键是一个字符串
OK 
redis> MULTI
OK
redis> SADD fruit "apple" "banana" "cherry"
QUEUED
redis> RPUSH msg "good bye" "bye bye"     # 错误地对字符串键msg执行列表键的命令
QUEUED 
redis> SADD alphabet "a" "b" "c"
QUEUED
redis> EXEC
1) (integer) 3
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
3) (integer) 3

Redis 的作者在事务功能的文档中解释说，不支持事务回滚是因为这种复杂的功能和 Redis 追求简单高效的设计主旨不相符，并且他认为，Redis 事务的执行时错误通常是变成错误产生的，这种错误通常只会出现在开发环境中，而很少会在实际的生产环境中出现，所以他认为没有必要为 Redis 开发事务回滚功能。

3.2 一致性

事务具有一致性指的是，如果数据库在执行事务之前是一致的，那么在事务只想之后，无论事务是否执行成功，数据库也应该仍然是一致的。

“一致”指的是数据符合数据库本身的定义和要求，没有包含非法或者无效的错误数据。

Redis 通过谨慎的错误检测和简单的设计来保证事务的一致性，以下分别介绍三个 Redis 事务可能出错的地方，并说明 Redis 是如何妥善处理这些错误，从而确保事务的一致性的。

1. 入队错误

如果一个事务在入队命令的过程中，出现了命令不存在，或者命令的格式不正确等情况，那么 Redis 将拒绝执行这个事务。

在以下展示的示例中，因为客户端尝试向事务如归一个不存在的命令 YAHOOOO，所以客户端提交的事务会被服务器拒绝执行：

redis> MULTI
OK
redis> SET msg "hello"
QUEUED
redis> YAHOOOO
(error) ERR unknown command 'YAHOOOO'
redis> GET msg
QUEUED
redis> EXEC
(error) EXECABORT Transaction discarded because of previous errors.

因为服务器会拒绝入队过程中出现错误的事务，所以 Redis 事务的一致性不会被带有入队错误的事务影响。

在 Redis 2.6.5 以前的版本，即使有命令在入队过程中发生了错误，事务一样可以执行，不过被执行的命令只包括那些正确入队的命令。

因为错误的命令不会被入队，所以 Redis 不会尝试去执行错误的命令，因此即使在 2.6.5以前的版本中，Redis 事务的一致性也是不会被入队错误影响。

2. 执行错误

除了入队时可能发生错误以外，事务还可能在执行的过程中发生错误。关于这种错误有两个需要说明的地方：

• 执行过程中发生的错误都是一些在入队时不能被服务器发现的错误，这些错误只会在命令实际执行是被触发；
• 即使在事务的执行过程中发生了错误，服务器也不会中断事务的执行，它会继续执行事务中余下的其他命令，并且已执行的命令（包括执行命令所产生的的结果）不会被出错的命令影响。

对数据库键执行了错误类型的操作是事务执行期间最常见的错误之一。

因为在事务执行的过程中，出错的命令会被服务器识别出来，并进行相应的错误处理，所以这些错误命令不会对数据库做任何修改，也不会对事物的一致性产生任何影响。

3. 服务器停机

如果 Redis 服务器在执行事务的过程中停机，那么根据服务器所使用的持久化模式，可能有以下情况出现：

• 如果服务器运行在无持久化的过程中停机，那么重启之后的数据库将是空白的，因此数据总是一致的；
• 如果服务器运行在 RDB 模式下，那么在事务中途停机不会导致不一致性，因为服务器可以根据现有的 RDB 文件来恢复数据，从而将数据库还原到一个一致的状态。如果找不到可供用的 RDB 文件，那么重启之后的数据库将是空白的，二空白数据库总是一致的；
• 如果服务器运行在 AOF 模式下，那么在事务中途停机不会导致不一致性，因为服务器可以根据现有的 AOF 文件来恢复数据，从而将数据库还原到一个一致的状态。如果找不到可用的 AOF 文件，那么重启之后的数据库将是空白的，而空白数据库总是一致的。

综上所述，无论 Redis 服务器运行在哪种持久化模式下，事务执行中途发生的停机都不会影响数据库的一致性。

3.3 隔离性

事务的隔离性指的是，即使数据库中多个事务并发地执行，各个事务之间不会互相影响，并且在并发状态下执行的事务和串行执行的事务产生的结果完全相同。

Redis 队列中的命令在事务没有被提交之前不会被实际执行，因为 Redis 使用单线程的方式来执行事务（以及事务队列中的命令），事务中的所有命令会被序列化、按顺序执行，并且服务器保证，在执行事务期间不会被其他客户端发送来的命令打断，因此，Redis 的事务总是以串行的方式运行的，并且事务也总是具有隔离性的。

3.4 持久性

事务的持久性指的是，当一个事务执行完毕时，执行这个事务所得的结果已经被保存到永久储存介质（比如硬盘）里面，即使服务器在事务执行完毕之后停机，执行事务得的结果也不会丢失。

因为 Redis 的事务不过是简单地用队列包裹起了一组 Redis 命令，Redis 并没有为事务提供任何额外的持久化功能，所以 Redis 事务的持久性由 Redis 所使用的持久化模式决定：

1. 当服务器在无持久化的内存模式下运作时，事务不具有持久性：一旦服务器停机，包括事务数据在内的所有服务器数据都将丢失；
2. 当服务器在 RDB 持久化模式下运作时，服务器只会在特定的保存条件被满足时，才会执行 BGSAVE 命令，对数据库进行保存操作，并且异步执行的 BGSAVE 不能保证事务数据被第一时间保存到硬盘里，因此 RDB 持久化模式下的事务不具有持久性；
3. 当服务器运行在 AOF 持久化模式下，并且 appendfsync 选项的值为 always 时，程序总会在执行命令之后调用同步（sync）函数，将命令数据真正保存到硬盘里，因此这种配置下的事务是具有持久性的。
4. 当服务器运行在 AOF 持久化模式下，并且  appendfsync 选项的值为 everysec 时，程序会每秒同步一次命令数据导硬盘。因此停机可能会恰好发生在等待同步的那一秒钟内，这可能会造成事务数据丢失，所以这种配置下的事务不具有持久性；
5. 当服务器运行在 AOF 持久化模式下，并且  appendfsync 选项的值为 no 时，程序会交由操作系统来决定何时将命令数据同步到硬盘。因为事务数据可能在等待同步的过程中丢失，所以这种配置下的事务不具有持久性。

配置选项 no-appendfsync-no-write 可以配合 appendfsync 选项为 always 或者 everysec 的 AOF 持久化模式使用。当 no-appendfsync-no-write 选项处于打开状态时，在执行 BGSAVE 命令或者 BGREWRITEAOF 命令期间，服务器会暂时停止对 AOF 进行同步，从而尽可能地减少 I/O 阻塞。但是这样一来，关于 “always 模式的 AOF 持久化可以保证事务的持久性”这一结论将不再成立，因为在服务器停止对 AOF 文件进行同步期间，事务结果可能会因为停机而丢失。因此，如果服务器打开了 no-appendfsync-no-write 选项，那么即便服务器运行在 always 模式的 AOF 持久之下，事务也不具有持久性。在默认配置下，no-appendfsync-no-write 处于关闭状态。

不论 Redis 在什么模式下运作，在一个事务的最后加上 SAVE 命令总可以保证事务的持久性：

redis> MULTI
OK
redis> SET msg "hello"
QUEUED
redis> SAVE
QUEUED
redis> EXEC
1)OK
2)OK

不过因为这种做法的效率太低，所以不具有实用性。

---

4 重点总结

1. 事务提供了一种将多个命令打包，然后一次性、有序地执行的机制；
2. 多个命令会被入队到事务队列中，然后按先进先出（FIFO）的顺序执行；
3. 事务在执行过程中不会被中断，当事务队列中的所有命令都被执行完毕之后，事务才会结束；
4. 带有 WATCH 命令的事务会将客户端和被监视的键在数据库的 watched_keys 字典汇总进行关联，当键被修改时，程序会将所有监视被修改的客户端 REDIS_DIRTY_CAS 标志打开；
5. 只有在客户端的 REDIS_DIRTY_CAS 标志未被打开时，服务器才会执行客户端提交的事务，否则的话，服务器将拒绝执行客户端提交的事务；
6. Redis 的事务总是具有 ACID 中的原子性、一致性和隔离性，当服务器运行在 AOF 持久化模式下，并且 appendfsync 选择值为 always 时，事务具有持久性。

 

参考：

 《Redis设计与实现》 黄健宏 著