-
multi
开启一个事务，原理是开启客户端属性中的事务开关标示REDIS_MULTI，将客户端从非事务状态切换到事务状态，之后该客户端的所有命令（除了事务相关的几个命令）都不会直接执行，而是存到一个事务队列中，然后向客户端返回 QUEUED 回复。Redis 的事务是不可嵌套的， 当客户端已经处于事务状态， 而客户端又再向服务器发送 MULTI时， 服务器只是简单地向客户端发送一个错误， 然后继续等待其他命令的入队。 MULTI命令的发送不会造成整个事务失败， 也不会修改事务队列中已有的数据。
Paste_Image.png
事务状态包含一个事务队列， 以及一个已入队命令的计数器，事务队列是一个 multiCmd 类型的数组， 数组中的每个 multiCmd 结构都保存了一个已入队命令的相关信息， 包括指向命令实现函数的指针， 命令的参数， 以及参数的数量。
watch
可以监视用于在事务开始之前监视任意数量的键： 当调用 EXEC命令执行事务时， 如果任意一个被监视的键已经被其他客户端修改了， 那么整个事务不再执行， 直接返回失败。只能在客户端进入事务状态之前执行， 在事务状态下发送 WATCH命令会引发一个错误， 但它不会造成整个事务失败， 也不会修改事务队列中已有的数据（和前面处理 MULTI的情况一样）。
实现原理：
在每个代表数据库的 redis.h/redisDb结构类型中， 都保存了一个watched_keys字典， 字典的键是这个数据库被监视的键， 而字典的值则是一个链表， 链表中保存了所有监视这个键的客户端。
比如说，以下字典就展示了一个 watched_keys
字典的例子：
其中， 键 key1正在被 client2 、 client5和 client1三个客户端监视， 其他一些键也分别被其他别的客户端监视着。
WATCH命令的作用， 就是将当前客户端和要监视的键在 watched_keys
中进行关联。
举个例子， 如果当前客户端为 client10086， 那么当客户端执行 WATCH key1 key2时， 前面展示的 watched_keys将被修改成这个样子：
通过 watched_keys 字典， 如果程序想检查某个键是否被监视， 那么它只要检查字典中是否存在这个键即可； 如果程序要获取监视某个键的所有客户端， 那么只要取出键的值（一个链表）， 然后对链表进行遍历即可。
在任何对数据库键空间（key space）进行修改的命令成功执行之后 （比如 FLUSHDB、SET、DEL、 LPUSH、SADD 、 ZREM，诸如此类）， multi.c/touchWatchedKey
函数都会被调用 —— 它检查数据库的 watched_keys字典， 看是否有客户端在监视已经被命令修改的键， 如果有的话， 程序将所有监视这个/这些被修改键的客户端的 REDIS_DIRTY_CAS选项打开：
当客户端发送 EXEC命令、触发事务执行时， 服务器会对客户端的状态进行检查：
如果客户端的 REDIS_DIRTY_CAS选项已经被打开，那么说明被客户端监视的键至少有一个已经被修改了，事务的安全性已经被破坏。服务器会放弃执行这个事务，直接向客户端返回空回复，表示事务执行失败。
如果 REDIS_DIRTY_CAS选项没有被打开，那么说明所有监视键都安全，服务器正式执行事务。
- EXEC
提交事务。按顺序执行队列中的命令，最后将执行命令所得的结果全部返回给客户端。 - DISCARD
取消事务。清空事务队列，关闭客户端事务开关，切换事务状态。
事务中的命令和普通命令在执行上的相同与不同：
相同点：无论在事务状态下， 还是在非事务状态下， Redis 命令都由同一个函数执行， 所以它们共享很多服务器的一般设置， 比如 AOF 的配置、RDB 的配置，以及内存限制，等等。
不同点：
- 非事务状态下的命令以单个命令为单位执行，前一个命令和后一个命令的客户端不一定是同一个；
而事务状态则是以一个事务为单位，执行事务队列中的所有命令：除非当前事务执行完毕，否则服务器不会中断事务，也不会执行其他客户端的其他命令。 - 在非事务状态下，执行命令所得的结果会立即被返回给客户端；
而事务则是将所有命令的结果集合到回复队列，再作为 EXEC命令的结果返回给客户端。
