Redis事务通过MULTI、EXEC、WATCH等命令来实现。事务提供一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会执行其他客户端的命令请求。
事务的实现
事务的三个阶段：
事务开始
MULTI命令会将客户端的flags属性打开REDIS_MULTI标识，意味着事务开始。命令入队
当客户端处于事务状态时，服务器根据不同的命令会有不同的表现：
- 若是EXEC、DISCARD、WATCH、MULTI命令，则服务器立即执行命令；
-
否则，命令放入一个事务队列中。
image
每个Redis客户端都有自己的事务状态，保存在mstate属性中，mstate中包含一个事务队列，事务队列是一个multiCmd数组，数组中每个元素保存了一个已入队命令的相关信息：
typedef struct redisClient {
... ...
multiState mstate; // 事务状态
... ...
} redisClient;
typedef struct multiState {
multiCmd *commands; // 事务队列，FIFO顺序
int count; // 已入队命令计数
} multiState;
typedef struct multiCmd {
robj **argv; // 参数
int argc; // 参数数量
struct redisCommand *cmd; // 命令指针
} multiCmd;
- 事务执行
当一个处于事务状态的客户端向服务器发送EXEC命令时，服务器会遍历这个客户端的事务队列，执行队列中保存的所有命令，最后将执行命令所得到的结果全部返回给客户端。
WATCH命令的实现
WATCH命令是一个乐观锁，在EXEC命令执行之前监视任意数量的数据库键，并在EXEC执行时，检查被监视的键是否有被修改过了（被另一个客户端修改了），如果是的话服务器将拒绝执行事务，并向客户端返回表示事务执行失败的空回复。
每个Redis数据库都保存着一个watch_keys字典，键是被WATCH命令监视的数据键，值是一个链表，链表记录了所有监视对应键的客户端：
typedef struct redisDb {
... ...
dict *watch_keys; // 正被WATCH监视的键
... ...
} redisDb;
所有对数据库进行修改的命令，包括SET、LPUSH、SADD、ZREM、DEL、FLUSHDB等，在执行之后都会对watch_keys进行检查，查看是否有客户端正在监视刚刚被修改的数据库键，若有则将被修改键的客户端的REDIS_DIRTY_CAS标识打开，表示盖客户端的事务安全性已经被破坏。
当服务器接收到客户端发来的EXEC命令，服务器根据这个客户端是否打开了REDIS_DIRTY_CAS标识来决定是否执行事务：
事务的ACID性质
事务的ACID性质：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和耐久性（Durability）。
- 原子性
事务的原子性是指数据库将事务中的多个操作当作一个整体来执行，服务器要么就执行所有的操作，要么一个操作也不执行。
Redis不支持事务回滚机制，即使事务队列中某个命令在执行期间出现错误，整个事务也会继续执行下去，直到将事务队列的所有命令都执行完毕为止。 - 一致性
事务的一致性是指如果事务执行之前是一致的，那么事务执行之后，无论事务是否执行成功，数据库也应该是一致的。一致指的是数据符合数据库本身的定义和要求，没有包含非法或者无效的错误数据。
Redis通过错误检测和简单的设计来保证事务的一致性：- 入队错误
如果一个事务在入队命令的过程中，出现了命令不存在火灾命令格式错误等情况，那么Redis将拒绝执行这个事务。 - 执行错误
事务执行过程中还可能出现错误，这些错误无法在入队时发现，只会在执行时触发；即使在事务执行过程中发生了错误，服务器也不会中断事务的执行，它会继续执行事务中余下的其他命令，并且已执行的命令不会被出错的命令影响。 - 服务器停机
若Redis服务器在执行事务时停机，那么根据使用的持久化模式，可能有以下情况：- 若服务器运行在无持久化的内存模式下，那么重启后数据库将是空白的，因此数据总是一致的；
- 若服务器运行在RDB模式下，那么事务在中途停机不会导致不一致性，因为服务器可以根据现有的RDB文件来恢复数据，从而将数据库还原到一个一致状态。如果找不到RDB文件，那么重启后数据库将是空白的，也是一致的；
- 若服务器运行在AOF模式下，那么事务在中途停机不会导致不一致性，因为服务器可以根据现有的AOF文件来恢复数据，从而将数据库还原到一个一致状态。如果找不到AOF文件，那么重启后数据库将是空白的，也是一致的。
- 入队错误
- 隔离性
事务的隔离性指的是即使数据库中多个事务并发地执行，各个事务之间也不会相互影响，并且在并发状态下执行的事务和串行执行的事务产生的结果相同。 - 耐久性
事务的耐久性是指当一个事务执行完毕，执行这个事务所得的结果已被保存到永久性存储介质中，即使服务器在事务执行完毕后停机，事务所得结果也不会丢失。
因为Redis事务使用队列包裹一组Redis命令，并没有提供持久化功能，所以Redis事务的耐久性由Redis所使用的持久化模式决定：- 当服务器在无持久化的内存模式下运行，事务不具有耐久性：一旦服务器停机，所有数据库数据都将丢失；
- 当服务器运行在RDB模式，服务器只会在特定的保存条件被满足时才会执行BGSAVE命令保存数据，并且BGSAVE不能保证事务数据被第一时间保存到硬盘中，因此不具有耐久性；
- 当服务器运行在AOF模式，并且appendfsync选项的值为always时，程序总会在执行命令之后调用同步函数，并将数据真正保存到硬盘里，具有耐久性；
- 当服务器运行在AOF模式，并且appendfsync选项的值为everysec时，程序每秒会同步一次数据，若是停机刚好发送在等待同步的1s内，则会造成数据丢失，不具有耐久性；
- 当服务器运行在AOF模式，并且appendfsync选项的值为no时，程序交由操作系统来决定何时将数据同步到硬盘中，数据可能在等待同步的过程中丢失，不具有耐久性；
