1. 概述
Redis单条命令的执行可以保证原子性，但是如果需要保证多个命令执行的原子性，就需要使用到Redis的事务。Redis的事务有如下特点：
- 事务中的所有命令可以保证顺序的执行，不会出现事务执行过程中，被其他事务的命令中断。
- 事务中的命令要么所有的都被执行，要么所有的都不执行（这里说的执行，不是说的执行成功）。
2. 基本用法
2.1 基本命令
- MULTI：该命令是事务的入口，该命令之后的所有命令都只会被放入队列；
- EXEC：该命令是事务的结束，使用该命令之后，事务队列中的所有命令开始执行；
- DISCARD：该命令也是事务的结束，使用该命令之后，将会丢弃事务队列中的命令。
2.2 用法举例
2.2.1 正常执行
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET k1 v1
QUEUED
127.0.0.1:6379> SET k2 v2
QUEUED
127.0.0.1:6379> GET k1
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) OK
3) "v1"
127.0.0.1:6379> GET k1
"v1"
127.0.0.1:6379> get k2
"v2"
EXEC执行的结果是一个数组，数组中每个元素是事务中一条命令的执行结果，结果的顺序按照命令进入队列顺序排列。
2.2.2 放弃事务
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 v11
QUEUED
127.0.0.1:6379> set k2 v22
QUEUED
127.0.0.1:6379> DISCARD
OK
127.0.0.1:6379> get k1
"v1"
127.0.0.1:6379> get k2
"v2"
执行DISCARD命令后，所有指令都放弃执行，k1和k2的值都没有修改。
2.2.3 语法错误
在EXEC命令执行前，入队列的命令可能会因为语法错误（命令名称或者命令参数错误），或者因为Redis服务器内存不足，而入队列失败。
Redis 2.6.5之后的版本，Redis会记住在命令入队列时存在错误，并在运行EXEC命令时，拒绝执行事务并返回一个错误。Redis 2.6.5之前的版本，可以通过指定EXEC忽略错误，而只执行正确的命令。
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> INC k1
(error) ERR unknown command `INC`, with args beginning with: `k1`,
127.0.0.1:6379> inc k2
(error) ERR unknown command `inc`, with args beginning with: `k2`,
127.0.0.1:6379> set k2 v22
QUEUED
127.0.0.1:6379> EXEC
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get k1
"v1"
127.0.0.1:6379> get k2
"v2"
可以看到，输入命令时就返回了错误，并且在执行EXEC时，也返回了错误。就算“set k2 v22”是正确的命令，但是也放弃执行了，最后k1和k2的值都未修改。
2.2.4 命令执行错误
在EXEC执行之后，队列中的命令可能执行失败，比如对string类型的数据运行INCR指令。Redis遇到这样的错误，不会放弃事务，会继续执行正确的命令。
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> incr k1
QUEUED
127.0.0.1:6379> set k2 v22
QUEUED
127.0.0.1:6379> EXEC
1) (error) ERR value is not an integer or out of range
2) OK
127.0.0.1:6379> get k1
"v1"
127.0.0.1:6379> get k2
"v22"
可以看到incr k1并没有执行成功，但是set k2 v22执行成功了。EXEC的结果与正常执行的结果一致，事务中各个指令的结果以数组的形式返回。
为什么Redis不实现回滚呢？
既然redis提供的是事务，为什么不跟RDB一样，在命令执行错误时，将整个事务回滚，而是要继续执行后续正确的命令呢？Redis团队的观点如下：
- 这种场景下命令执行失败的原因可能是语法错误（并且是在输入命令时不能检测到的错误）或者key对应的数据类型不正确。这意味着出现这样的错误很可能是程序的bug，很有可能在开发过程中就能解决的，而不会延续的生产环境才发现。
- 为了保证Redis的简单快速特性，如果引入回滚，就会影响到Redis的性能。
2.3 乐观锁（CAS）
WATCH命令用来为Redis的事务提供CAS功能，如果有一个watch的key在EXEC执行之前被修改过，那么整个事务都会退出并且EXEC返回一个nil。
2.3.1 事例
- 打开两个Redis客户端，在第一个客户端中输入如下命令：
127.0.0.1:6379> watch k1
OK
- 在第二个客户端输入（其实这个命令在客户端1执行，但是必须在multi之前，结果也是一样的）：
127.0.0.1:6379> set k1 v111
OK
- 回到客户端1，输入：
127.0.0.1:6379> multi
OK
127.0.0.1:6379> SET k1 v11
QUEUED
127.0.0.1:6379> set k2 v22
QUEUED
127.0.0.1:6379> EXEC
(nil)
127.0.0.1:6379> get k1
"v111"
127.0.0.1:6379> get k2
"v2"
可以看到，在客户端1的事务EXEC执行时，返回了nil，表示事务没有执行成功，并且k1和k2的值并没有受到事务中的命令的影响。
2.3.2 总结
- WATCH不能在事务过程中运行，也就是不能在MULTI和EXEC命令之间运行WATCH；
- 只要开始了WATCH，不管在MULTI之前（当前客户端或者另一个客户端）还是MULTI之后（必须在另外一个客户端）修改，（只要在EXEC之前修改）事务都会退出；
- 一但执行 EXEC开启事务的执行后，无论事务使用执行成功， WATCH对变量的监控都将被取消。
如果连接断开，WATCH也将自动停止。
也可以通过UNWATCH手动取消。 - 如果WATCH的是一个定时key，如果key在EXEC时过期了，则事务仍然可以执行成功。但是如果在过期前修改过，然后再过期，则事务会执行失败；
3. 实现原理
要了解Redis事务的实现原理，无非就是了解以下几点：
- 执行MULTI命令时，Redis是怎么处理的？
- 执行MULTI命令后，Redis是怎么将命令入队列的？队列的结构是怎样的？
- 执行EXEC命令时，Redis是怎么处理的？
- 执行DISCARD命令时，Redis是怎么处理的？
- 执行WATCH后，Redis会怎么处理？
带着以上几点问题，下面逐一阅读源代码解答（源代码版本：5.0.7）。
3.1 MULTI原理
MULTI命令对应函数为：multi.c文件的multiCommand（），源码如下：
void multiCommand(client *c) {
if (c->flags & CLIENT_MULTI) {
addReplyError(c,"MULTI calls can not be nested");
return;
}
c->flags |= CLIENT_MULTI;
addReply(c,shared.ok);
}
运行MULTI命令后，即为client打上了CLIENT_MULTI标记，并返回OK。
扩展
- client的flags为int类型，占4个字节，即32位；
- CLIENT_MULTI定义为#define CLIENT_MULTI (1<<3)，即flags的从右数第四位表示客户端进入了事务。
3.2 命令入队列原理
我们知道，运行了MULTI命令后，其后的命令会被加入队列，并返回QUEUE。那么：
- Redis是怎么判断命令应该进入队列？
- 命令进入的是哪个队列？队列中的元素数据结构是怎样的？
- 如果命令出现语法错误，怎么处理？
3.2.1 判断是否进入队列
Redis处理命令的入口函数是server.c文件的processCommand（），关键源代码如下：
int processCommand(client *c) {
// 省略前方部分代码
/* Exec the command */
if (c->flags & CLIENT_MULTI &&
c->cmd->proc != execCommand && c->cmd->proc != discardCommand &&
c->cmd->proc != multiCommand && c->cmd->proc != watchCommand)
{
queueMultiCommand(c);
addReply(c,shared.queued);
} else {
call(c,CMD_CALL_FULL);
c->woff = server.master_repl_offset;
if (listLength(server.ready_keys))
handleClientsBlockedOnKeys();
}
return C_OK;
}
第一个if判断客户端是否已经开启事务，如果开启，并且当前命令不是EXEC、DISCARD、MULTI、WATCH，则会调用queueMultiCommand(c)函数将命令放入队列。
3.2.2 进入的是哪个队列
/* Add a new command into the MULTI commands queue */
void queueMultiCommand(client *c) {
multiCmd *mc;
int j;
c->mstate.commands = zrealloc(c->mstate.commands,
sizeof(multiCmd)*(c->mstate.count+1));
mc = c->mstate.commands+c->mstate.count;
mc->cmd = c->cmd;
mc->argc = c->argc;
mc->argv = zmalloc(sizeof(robj*)*c->argc);
memcpy(mc->argv,c->argv,sizeof(robj*)*c->argc);
for (j = 0; j < c->argc; j++)
incrRefCount(mc->argv[j]);
c->mstate.count++;
c->mstate.cmd_flags |= c->cmd->flags;
}
可以看出，命令被放入的队列为client的mstate的commands数组。
3.2.3 队列数据结构
client.mstate
mstate的定义在server.h文件中，用于存储客户端的事务数据，命令会被保存到commands数组中。
typedef struct multiState {
// 事务命令数组
multiCmd *commands; /* Array of MULTI commands */
// 命令总个数
int count; /* Total number of MULTI commands */
int cmd_flags; /* The accumulated command flags OR-ed together.
So if at least a command has a given flag, it
will be set in this field. */
int minreplicas; /* MINREPLICAS for synchronous replication */
time_t minreplicas_timeout; /* MINREPLICAS timeout as unixtime. */
} multiState;
multiCmd
commands数组中保存的元素是什么结构呢？multiCmd定义在server.h文件中：
/* Client MULTI/EXEC state */
typedef struct multiCmd {
// 参数数组
robj **argv;
// 参数个数
int argc;
// 命令定义（命令名称、命令对应执行方法等）
struct redisCommand *cmd;
} multiCmd;
3.2.4 命令错误，怎么处理
回到server.c文件的processCommand（）方法，其中会判断命令是否正确。以命令语法检查代码为例：
int processCommand(client *c) {
// 省略前方部分代码
/* Now lookup the command and check ASAP about trivial error conditions
* such as wrong arity, bad command name and so forth. */
c->cmd = c->lastcmd = lookupCommand(c->argv[0]->ptr);
if (!c->cmd) {
flagTransaction(c);
sds args = sdsempty();
int i;
for (i=1; i < c->argc && sdslen(args) < 128; i++)
args = sdscatprintf(args, "`%.*s`, ", 128-(int)sdslen(args), (char*)c->argv[i]->ptr);
addReplyErrorFormat(c,"unknown command `%s`, with args beginning with: %s",
(char*)c->argv[0]->ptr, args);
sdsfree(args);
return C_OK;
} else if ((c->cmd->arity > 0 && c->cmd->arity != c->argc) ||
(c->argc < -c->cmd->arity)) {
flagTransaction(c);
addReplyErrorFormat(c,"wrong number of arguments for '%s' command",
c->cmd->name);
return C_OK;
}
// 省略后方部分代码
}
如果检查到命令不存在或者命令参数不正确，则会调用flagTransaction(c)标记事务，然后返回错误信息。
flagTransaction(c)
该函数的定义在multi.c文件中：
/* Flag the transacation as DIRTY_EXEC so that EXEC will fail.
* Should be called every time there is an error while queueing a command. */
void flagTransaction(client *c) {
if (c->flags & CLIENT_MULTI)
c->flags |= CLIENT_DIRTY_EXEC;
}
该函数的实现很简单，只是单纯的为客户端打上CLIENT_DIRTY_EXEC标记，当运行EXEC命令时，检查到该标记，则直接放弃运行。
扩展
- client的flags为int类型，占4个字节，即32位；
- CLIENT_DIRTY_EXEC定义为#define CLIENT_DIRTY_EXEC (1<<12)，也即flags的从右数第13位表示客户端事务需要放弃执行。
3.3 EXEC原理
EXEC对应的函数是multi.c文件中的execCommand()，主要源代码为：
void execCommand(client *c) {
// ...省略部分代码
// 1.
if (!(c->flags & CLIENT_MULTI)) {
addReplyError(c,"EXEC without MULTI");
return;
}
/* Check if we need to abort the EXEC because:
* 1) Some WATCHed key was touched.
* 2) There was a previous error while queueing commands.
* A failed EXEC in the first case returns a multi bulk nil object
* (technically it is not an error but a special behavior), while
* in the second an EXECABORT error is returned. */
// 2.
if (c->flags & (CLIENT_DIRTY_CAS|CLIENT_DIRTY_EXEC)) {
addReply(c, c->flags & CLIENT_DIRTY_EXEC ? shared.execaborterr :
shared.nullmultibulk);
discardTransaction(c);
goto handle_monitor;
}
// ...省略部分代码
// 3.
for (j = 0; j < c->mstate.count; j++) {
c->argc = c->mstate.commands[j].argc;
c->argv = c->mstate.commands[j].argv;
c->cmd = c->mstate.commands[j].cmd;
/* Propagate a MULTI request once we encounter the first command which
* is not readonly nor an administrative one.
* This way we'll deliver the MULTI/..../EXEC block as a whole and
* both the AOF and the replication link will have the same consistency
* and atomicity guarantees. */
if (!must_propagate && !(c->cmd->flags & (CMD_READONLY|CMD_ADMIN))) {
execCommandPropagateMulti(c);
must_propagate = 1;
}
call(c,server.loading ? CMD_CALL_NONE : CMD_CALL_FULL);
/* Commands may alter argc/argv, restore mstate. */
c->mstate.commands[j].argc = c->argc;
c->mstate.commands[j].argv = c->argv;
c->mstate.commands[j].cmd = c->cmd;
}
// ...省略部分代码
}
代码主要包括4个逻辑：
- 判断是否执行MULTI了，否则不能运行EXEC；
- 判断是否有CLIENT_DIRTY_CAS或者CLIENT_DIRTY_EXEC标记，有则放弃执行事务；
- 遍历multiState的指令数组，逐个执行指令；
- 执行完成，清理事务资源，调用discardTransaction(c)函数。
3.4 DISCARD原理
对应的函数是multi.c文件中的discardCommand()函数：
void discardCommand(client *c) {
if (!(c->flags & CLIENT_MULTI)) {
addReplyError(c,"DISCARD without MULTI");
return;
}
discardTransaction(c);
addReply(c,shared.ok);
}
执行DISCARD命令时，会调用discardTransaction(c)函数，对事务进行清理。
discardTransaction(c)
void discardTransaction(client *c) {
// 释放事务所占资源（命令数组、命令）
freeClientMultiState(c);
// 重置事务资源（命令数组设置为null、命令个数置为0）
initClientMultiState(c);
// 清理事务标记
c->flags &= ~(CLIENT_MULTI|CLIENT_DIRTY_CAS|CLIENT_DIRTY_EXEC);
// 清理watch的key
unwatchAllKeys(c);
}
概括起来，该函数主要用于释放事务相关资源，清除内存的占用。
3.5 WATCH原理
了解WATCH原理，主要是了解以下几点：
3.5.1 WATCH执行时，怎么处理？
很简单，必须要将watch的key的信息保存起来，Redis是怎么处理以及怎么保存的呢？
对应函数为multi.c文件中的watchCommand()：
void watchCommand(client *c) {
int j;
if (c->flags & CLIENT_MULTI) {
addReplyError(c,"WATCH inside MULTI is not allowed");
return;
}
for (j = 1; j < c->argc; j++)
watchForKey(c,c->argv[j]);
addReply(c,shared.ok);
}
该方法核心是调用watchForKey()，负责保存watch信息：
/* Watch for the specified key */
void watchForKey(client *c, robj *key) {
// ...省略部分代码
watchedKey *wk;
/* Check if we are already watching for this key */
listRewind(c->watched_keys,&li);
while((ln = listNext(&li))) {
wk = listNodeValue(ln);
if (wk->db == c->db && equalStringObjects(key,wk->key))
return; /* Key already watched */
}
/* This key is not already watched in this DB. Let's add it */
clients = dictFetchValue(c->db->watched_keys,key);
if (!clients) {
clients = listCreate();
dictAdd(c->db->watched_keys,key,clients);
incrRefCount(key);
}
listAddNodeTail(clients,c);
/* Add the new key to the list of keys watched by this client */
wk = zmalloc(sizeof(*wk));
wk->key = key;
wk->db = c->db;
incrRefCount(key);
listAddNodeTail(c->watched_keys,wk);
}
可以看出：
Redis会在DB中保存一份watch key的clients数组，数组元素为client。
Redis会在client中保存一份watch的所有key的数组，数组元素为watchedKey，结构为：
typedef struct watchedKey {
robj *key;
redisDb *db;
} watchedKey;
- Redis会根据client中保存的数组来判断客户端是否已经watch了。
3.5.2 WATCH的key被修改时，怎么处理？
DB中的key每一次被修改时，都会调用db.c文件中的signalModifiedKey()方法，该方法的核心是调用multi.c文件中的touchWatchedKey()：
/* "Touch" a key, so that if this key is being WATCHed by some client the
* next EXEC will fail. */
void touchWatchedKey(redisDb *db, robj *key) {
list *clients;
listIter li;
listNode *ln;
if (dictSize(db->watched_keys) == 0) return;
clients = dictFetchValue(db->watched_keys, key);
if (!clients) return;
/* Mark all the clients watching this key as CLIENT_DIRTY_CAS */
/* Check if we are already watching for this key */
listRewind(clients,&li);
while((ln = listNext(&li))) {
client *c = listNodeValue(ln);
c->flags |= CLIENT_DIRTY_CAS;
}
}
该方法会检查DB中保存的watched_keys信息，如果检查到当前修改的key被watch了，则标记对应的client为CLIENT_DIRTY_CAS。后面EXEC命令执行时，检查到有该标记，就会放弃事务的执行。
3.5.3 怎么UNWATCH？
我们知道有三种方式可以UNWATCH一个key：
- 事务EXEC/DISCARD
- 客户端断开连接(networking.c文件的freeClient()函数)
- 调用UNWATCH指令(multi.c文件的unwatchCommand()函数)
这三种场景下都会调用multi.c文件中的unwatchAllKeys()：
/* Unwatch all the keys watched by this client. To clean the EXEC dirty
* flag is up to the caller. */
void unwatchAllKeys(client *c) {
listIter li;
listNode *ln;
if (listLength(c->watched_keys) == 0) return;
listRewind(c->watched_keys,&li);
while((ln = listNext(&li))) {
list *clients;
watchedKey *wk;
/* Lookup the watched key -> clients list and remove the client
* from the list */
wk = listNodeValue(ln);
clients = dictFetchValue(wk->db->watched_keys, wk->key);
serverAssertWithInfo(c,NULL,clients != NULL);
listDelNode(clients,listSearchKey(clients,c));
/* Kill the entry at all if this was the only client */
if (listLength(clients) == 0)
dictDelete(wk->db->watched_keys, wk->key);
/* Remove this watched key from the client->watched list */
listDelNode(c->watched_keys,ln);
decrRefCount(wk->key);
zfree(wk);
}
}
该函数会：
- 清除DB中保存的watch 客户端，如果处理该客户端外，没有其他客户端watch了，则直接删除该key的watch信息；
- 清楚client的所有watch key信息。
4. 总结
- Redis事务与传统RDB提供的事务区别还是挺大的，其实只是简单的为了原子性的执行多个命令而设计的罢了；
- Redis实现事务的代码也是很直观的，没有什么特殊的逻辑。建议在看源代码之前，可以先想想如果是自己实现，会怎么处理。然后带着问题去看源代码，就可以快速理解Redis为什么会这么实现了。
