0%

Redis 设计与实现-事务

发表于 更新于 分类于 ， 阅读次数： Valine：
本文字数： 1.7k 阅读时长 ≈ 2 分钟

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

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

  1. 事务开始。
  2. 命令入队。
  3. 事务执行。

本文接下来的内容将对这三个阶段进行介绍,说明一个事务从开始到结束的整个过程。

1 事务开始

MULTI和令的执行标志着事务的开始:

1
2
redis> MULTI
OK

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

2 命令入队

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

  • 如果客户端发送的命令为EXEC、DISCARD、WATCH、MULTT四个命令的其中一个,那么服务器立即执行这个命令。

  • 与此相反,如果客户端发送的命令是EXEC、DISCARD、WATCH、MULTT四个命令以外的其他命令,那么服务器并不立即执行这个命令,而是将这个命令放入一个事务队列里面,然后向客户端返回QUEUED回复。

服务器判断命令是该入队还是该立即执行的过程可以用流程图19-1来描述。

3 事务队列

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

1
2
3
4
5
6
typedef struct redisClient {
    // ...
    // 事务状态
    mulitState mstate;
    // ...
} redisClient;

事务状态包含一个事务队列，以及一个已入队命令的计数器：

1
2
3
4
5
6
typedef struct mulitState {
    // 事务队列，FIFO顺序
    multiCmd *commands;
    // 已入队命令计数
    int count;
}mulitState

事务队列是一个 muliCmd 类型的数组，数组中的每个 multiCmd 结构都保存了一个已入队命令的相关信息：

1
2
3
4
5
typedef struct multiCmd {
    // ...
    // 命令指针
    struct redisCommand *cmd;
} multiCmd;

事务队列以先进先出(FIFO)的方式保存入队的命令,较先入队的命令会被放到数组的前面,而较后入队的命令则会被放到数组的后面。如下是示例图：

4 执行事务

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

5 WATCH 命令的实现

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

6 判断事务是否安全

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

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

这个判断是否执行事务的过程可以用流程图19-6来描述.

------ 本文结束------