Redis通过MULTI、EXEC、WATCH等命令来实现事务功能。事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令地机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求；
19.1 事务的实现
一个事务从开始到结束通常会经历以下三个阶段：事务开始、命令入队、事务执行；
19.1.1 事务开始
MULTI命令的执行标志着事务的开始；
MULTI命令可以将执行该命令的客户端从非事务状态切换至事务状态，切换的实现是通过在客户端状态的flags属性中打开REDIS_MULTI标识来完成的；
1 def MULTI(): 2 # 3 打开事务标识 4 client.flags |= REDIS_MULTI 5 # 6 返回OK 7 回复 8 replyOK()
19.1.2 命令入队
当一个客户端处于非事务状态时，客户端发送的命令会立刻被服务器执行；而当客户端处于事务状态时，服务器会根据客户端发送来的不同命令执行不同的操作；
- 如果客户端发送的命令为EXEC、DISCARD、WATCH、MULTI四个命令其中一个，那么服务器会立即执行该命令；
- 与此相反，如果客户端发送的命令是EXEC、DISCARD、WATCH、MULTI四个命令以外的其他命令，服务器并不会立即执行这个命令，而是将命令放入一个事务队列里面，然后向客户端返回QUEUED回复；
19.1.3 事务队列
每个Redis客户端都有自己的事务状态，事务状态保存在客户端状态的mstate属性里面；
1 typedef struct redisClient { 2 // ... 3 // 4 事务状态 5 multiState mstate; /* MULTI/EXEC state */ 6 // ... 7 } redisClient;
事务状态包含一个事务队列，以及一个已入队命令的计数器；
1 typedef struct multiState { 2 // 3 事务队列，FIFO 4 顺序 5 multiCmd *commands; 6 // 7 已入队命令计数 8 int count; 9 } multiState;
事务队列是一个multiCmd类型的数组，数组中的每个multiCmd结构都保存了一个已入队命令的相关信息，包括指向命令实现函数的指针、命令的参数、以及参数的数量；
1 typedef struct multiCmd { 2 // 3 参数 4 robj **argv; 5 // 6 参数数量 7 int argc; 8 // 9 命令指针 10 struct redisCommand *cmd; 11 } multiCmd;
事务队列以先进先出(FIFO)的方式保存入队的命令，较先入队的命令会被放到数组的前面，而较后入队的命令会被放到数组的后面；
19.1.4 执行事务
当一个处于事务状态的客户端向服务器发送EXEC命令时，这个EXEC命令将立即被服务器执行；服务器会遍历客户端的事务队列，执行队列中保存的所有命令，最后将执行命令所得的结果全部返回给客户端；
19.2 WATCH命令的实现
WATCH命令是一个乐观锁，它可以在EXEC命令执行之前，监视任意数量的数据库键，并在EXEC命令执行时，检查被监视的键是否至少有一个已经被修改过了，如果是的话，服务器将拒绝执行事务，并向客户端返回代表事务执行失败的空回复。
19.2.1 使用WATCH命令监视数据库键
每个Redis数据库都保存着一个watched_keys字典，字典的键是某个被WATCH命令监视的数据库键，字典的值是一个链表，链表中记录了所有监视相应数据库键的客户端；
1 typedef struct redisDb { 2 // ... 3 // 4 正在被WATCH 5 命令监视的键 6 dict *watched_keys; 7 // ... 8 } redisDb;
通过watched_keys字典，服务器可以清楚地知道哪些数据库键正在被监视，以及哪些客户端正在监视这些数据库键；
19.2.2 监视机制的触发
所有对数据库进行修改的命令，比如SET、LPUSH、SADD、ZREM、DEL、FLUSHDB等等，在执行之后都会调用touchWatchKey函数对watched_keys字典进行检查，查看是否有客户端正在监视刚刚被命令修改过的数据库键，如果有的话，touchWatchKey函数会将监视被修改键的客户端的REDIS_DIRTY_CAS标识打开，表示该客户端的事务安全性已经被破坏；
19.2.3 判断事务是否安全
当服务器接收到一个客户端发来的EXEC命令时，服务器会根据这个客户端是否打开了REDIS_DIRTY_CAS标识来决定是否执行事务；
- 如果客户端的REDIS_DIRTY_CAS标识已经被打开，说明客户端所监视的键当中，至少有一个键已经被修改过了，在这种情况下，客户端提交的事务已经不再安全，所以服务器会拒绝执行客户端提交的事务；
- 如果客户端的REDIS_DIRTY_CAS标识没有被打开，说明客户端监视的所有键都没有被修改过，事务仍然是安全的，服务器将执行客户端提交的这个事务；
19.3 事务的ACID性质
在Redis中，事务总是具有原子性、一致性、隔离性，并且当Redis运行在某种特定的持久化模式下时，事务也具有耐久性；
19.3.1 原子性
原子性：数据库将事务中的多个操作当作一个整体来执行，服务器要么执行事务中的所有操作，要么就一个操作也不执行；
Redis事务与传统关系型数据库事务的最大区别在于：Redis不支持事务回滚机制，即使事务队列中的某个命令在执行期间出现了错误，整个事务也会继续执行下去，直到将事务队列中的所有命令都执行完毕为止；
Redis作者解释：不支持事务回滚是因为回滚和Redis追求简单高效的设计主旨不相符，他认为Redis事务的执行时错误都是编程错误产生的，这种错误只会出现在开发环境中，而很少会在实际环境中出现，所以他认为没有必要为Redis开发事务回滚功能；
19.3.2 一致性
事务的一致性是指数据库在执行事务之前是一致的，那么在事务执行之后，无论事务是否执行成功，数据库也应该是一致的；
"一致"指的是数据符合数据库本身的定义和要求，没有包含非法或者无效的错误数据；
事务中的常见错误：
1). 入队错误：如果一个事务在入队命令的过程中，出现命令不存在，或者命令格式不正确的情况，Redis将拒绝执行这个事务；由于服务器会拒绝执行入队过程中出现错误的事务，因此Redis事务的一致性不会被带有入队错误的事务影响；
2). 执行错误：当事务中，出现对数据库键执行错误类型操作的命令时，服务器不会中断事务的执行，会继续执行事务中余下的其他命令，并且已执行的命令不会被出错的命令影响；
3). 服务器停机：如果Redis服务器在执行事务的过程中停机，则根据服务器使用的持久化模式，可能出现以下情况：
- 运行在无持久化的内存模式下，重启后的数据库将是空白的，数据是一致的；
- 服务器运行在RDB模式下，事务中途停机，服务器会根据现有的RDB文件来恢复数据，将数据库还原到一致状态，如果找不到可供使用的RDB文件，重启数据库将是空白的；
- 服务器运行在AOF模式下，事务中途停机，服务器会根据现有的AOF文件来恢复数据，将数据库还原到一致状态，如果找不到可供使用的AOF文件，重启数据库将是空白的；
19.3.3 隔离性
事务隔离性是指，即使数据库中有多个事务并发地执行，各个事务之间也不会相互影响，并且在并发状态下执行的事务和串行执行的事务产生的结果完全相同；
Redis使用单线程的方式来执行事务，并且服务器保证，在执行事务期间不会对事务进行中断，因此，Redis的事务总是以串行的方式运行的，并且事务总是有隔离性的；
19.3.4 耐久性
耐久性指当一个事务执行完毕，执行这个事务的结果会被保存到永久性存储介质里面，即使服务器在事务执行完毕之后停机，执行事务的结果也不会丢失；
Redis的事务不过是用队列包裹起的一组Redis命令，Redis并没有为事务提供任何额外的持久化功能，所以Redis事务的耐久性由Redis所使用的持久化模式决定；
在无持久化的内存模式下运作，事务不具有耐久性；一旦服务器停机，包括事务在内的所有服务器数据都将丢失；
当服务器在RDB持久化模式下运作，服务器只会在特定的保存条件被满足时，执行BGSAVE命令，异步执行的BGSAVE不能保证事务数据被第一时间保存到硬盘，因此RDB持久化模式下的事务也不具有耐久性；
当服务器运行在AOF持久化模式下，并且appendfsync=always时，程序总会在执行命令之后调用同步函数，将命令保存到硬盘里面，该配置下的事务具有耐久性；
当服务器运行在AOF持久化模式下，并且appendfsync=everysec时，程序会每秒同步一次命令数据到硬盘。停机可能恰好发生在等待同步的一秒钟之内，造成事务数据丢失，该配置下事务不具有耐久性；
当服务器运行在AOF持久化模式下，并且appendfsync=no时，程序会交由操作系统来决定何时将命令数据同步到硬盘，事务数据可能在等待同步的过程中丢失，因此这种配置下的事务不具有耐久性；
无论Redis在什么模式下运作，在一个事务的最后加上save命令总可以保证事务的耐久性；但这种做法效率太低，不具有实用性；
浙公网安备 33010602011771号