Abstract
为啥要取abstract，可能是因为最近看论文有点PTSD了
Redis通过MULTI、EXEC、WATCH等命令来实现事务功能。事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求
事务的实现
一个事务从开始到结束通常会经历以下三个阶段：
- 事务开始
- 命令入队
- 事务执行
事务开始
MULTI命令的执行标志着事务的开始
将执行该命令的客户端从非事务状态切换至事务状态，这一切换是通过在客户端状态的flags属性中打开REDIS_MULTI标识来完成的
这里的客户端指的是在Redis服务器中存着客户端状态的数据结构
命令入队
当一个客户端处于非事务状态时，这个客户端发送的命令会立即被服务器执行
但是，当一个客户端切换到事务状态之后，服务器会根据这个客户端发来的不同命令执行不同的操作
- 如果客户端发送的命令为EXEC、DISCARD、WATCH、MULTI四个命令的其中一个，那么服务器立即执行这个命令
- 如果客户端发送的命令是EXEC、DISCARD、WATCH、MULTI四个命令以外的其他命令，那么服务器并不立即执行这个命令，而是将这个命令放入一个事务队列里面，然后向客户端返回QUEUED回复
事务队列
每个Redis客户端都有自己的事务状态，这个事务状态保存在客户端状态的mstate属性里面
事务状态包含一个FIFO的事务队列，以及一个已入队命令的计数器，也就是事务队列的长度
事务队列是一个multiCmd类型的数组，数组中的每个multiCmd结构都保存了一个已入队命令的相关信息，包括指向命令实现函数的指针、命令的参数，以及参数的数量
1 | typedef struct redisClient redisClient;typedef struct multiState multiState;typedef struct multiCmd multiCmd; |
执行事务
当一个处于事务状态的客户端向服务器发送EXEC命令时，这个EXEC命令将立即被服务器执行。服务器会遍历这个客户端的事务队列，执行队列中保存的所有命令，最后将执行命令所得的结果全部返回给客户端
WATCH命令的实现
WATCH命令是一个乐观锁，他可以在EXEC命令执行之前，监视任意数量的数据库键，并在EXEC命令执行时，检查被监视的键是否至少有一个已经被修改过了，如果是的话，服务器将拒绝执行事务，并向客户端返回代表事务执行失败的空回复
接下来介绍下WATCH命令的实现原理，以及事务系统如何监视某个键，并在键被修改的情况下，确保事务的安全性
使用WATCH命令监视数据库键
每个Redis数据库都保存着一个watched_keys字典，这个字典的键是某个被WATCH命令监视的数据库键，字典的值则是一个链表，链表中记录了所有监视相应数据库键的客户端
通过这个字典，服务器可以清楚的知道哪些数据库键正在被监视，以及哪些客户端正在监视这些数据库键
监视机制的触发
所有对数据库进行修改的命令，在执行后都会调用相应的函数对watched_keys字典进行检查，查看是否有客户端正在监视刚刚被命令修改过的数据库键，如果有的话，那么这个函数就会将监视被修改键的客户端的REDIS_DIRTY_CAS标识打开，表示该客户端的事务安全性已经被破坏
判断事务是否安全
当服务器接收到一个客户端发来的EXEC命令时，服务器会根据这个客户端是否打开了REDIS_DIRTY_CAS标识来决定是否执行事务。如果这个标识没有被打开，就执行客户端提交的这个事务
事务的ACID性质
传统的关系数据库中，常常用ACID性质来校验事务功能的可靠性和安全性
在Redis中，事务总是具有原子性、一致性和隔离性，在Redis运行在某种特定的持久化模式中，事务也具有耐久性
原子性
对于Redis的事务功能来说，事务队列中的命令要么就全部都执行，要么就一个都不执行，因此，Redis的事务是具有原子性的
但是，Redis的事务和传统的关系型数据库事务的最大区别在于，Redis不支持事务回滚机制rollback，即使事务队列中的某个命令在执行期间出现了错误，整个事务也会继续执行下去，直到将事务队列中的所有命令都执行完毕为止
这是因为Redis的作者认为这种复杂的功能和Redis追求简单高效的设计主旨不相符，并且认为事务的执行时遇到错误通常都是编程错误产生的，这种错误通常只会出现在开发环境，没有必要开发事务回滚功能
一致性
一致性指数据符合数据库本身的定义和要求，没有包含非法或者无效的错误数据
Redis通过谨慎的错误检测和简单的设计来保证事务的一致性
隔离性
Redis在实际执行事务时是单线程的，并且，服务器保证在执行事务时不会对事务进行中断。Redis的事务总是以串行的方式运行的，总是具有隔离性的
持久性
Redis事务的持久性由Redis使用的持久化模式决定
但是，在一个事务的最后加上SAVE命令总可以保证事务的耐久性
不过这种做法效率较低，不具有实用性