本篇内容为大家介绍下Redis的事务，我们知道Redis的事务是通过MULTI、EXEC、WATCH等命令来实现事务(transaction)功能。事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令都执行完毕,然后才去处理其他客户端的命令请求。
一、事务执行过程简单说明
我们这里先使用简单的命令来演示一下事务执行的过程。该事务首先以一个MULTI命令为开始，接着将多个命令放入事务当中，最后由EXEC命令将这个事务提交（commit）给服务器执行。
[root@localhost bin]# ./redis-cli
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set "name" "Shiwk Common Lisp"
QUEUED
127.0.0.1:6379> get "name"
QUEUED
127.0.0.1:6379> set "author" "shiwk"
QUEUED
127.0.0.1:6379> get "author"
QUEUED
127.0.0.1:6379> exec
1) OK
2) "Shiwk Common Lisp"
3) OK
4) "shiwk"
127.0.0.1:6379>
下面的内容中，小编首先会介绍Redis如何使用MULTI和EXEC命令来实现事务功能，说明事务中的多个命令是如何被保存到事务里面的，而这些命令又是如何被执行的。
在介绍了事务的实现原理之后，我们将对WATCH命令的作用进行介绍，并说明WATCH命令的实现原理。
因为事务的安全性和可靠性也是大家关注的焦点，所以最后小编将以常见的ACID性质对Redis事务的原子性、一致性、隔离性和耐久性进行说明。
1.1事务的实现
一个事务从开始到结束通常会进过以下三个阶段：
（1）事务开始 （2）命令入队 （3）事务执行
接下来我们就对这个过程进行介绍，说明一个事务从开始到结束的整个过程。
（1）事务开始
MULTI命令的执行标志着事务的开始。
127.0.0.1:6379> multi
OK
MULTI命令可以将执行该命令的客户端从非事务状态切换至事务状态，这一切换是通过在客户端状态的flags属性中打开REDIS_MULTI标识来完成的，MULTI命令的实现可以用下面的伪代码来表示：
def MULTI()；
#打开事务标识
client.flags |= REDIS_MULTI
#返回ok回复
replyOK()
（2）命令入队
当一个客户端处于非事务状态时，这个客户端发送的命令会立即被服务器执行:
[root@localhost bin]# ./redis-cli
127.0.0.1:6379> set "name" "Shiwk Common Lisp"
OK
127.0.0.1:6379> get "name"
Shiwk Common Lisp
127.0.0.1:6379> set "author" "shiwk"
OK
127.0.0.1:6379> get "author"
shiwk
而当一个客户端处于事务状态时，服务器会根据客户端发来的不同命令执行不同的操作：
如果客户端发送的命令为EXEC、DISCARD、WATCH、MULTI四个命令的其中一个，那么服务器立即执行这个命令。
与此相反，如果客户端发送的命令是EXEC、DISCARD、WATCH、MULTI四个命令以外的其他命令，那么服务器并不立即执行这个命令，而是将这个命令放入一个事务队列里面，然后向客户端返回QUEUED回复。
服务器判断命令是该入队还是该立即执行的过程流程图描述：
上述图中事务队列解释：
每个Redis 客户端都有自己的事务状态，这个事务状态保存在客户端状态的mstate属性里面:
typedef struct redisClient{
...
// 事务状态
multiState mstate; /*multi/exec state */
...
} redisClient;
事务状态包含一个事务队列，以及一个已人队命令的计数器（也可以说是事务队列的长度):
typedef struct multiState{
// 事务队列，FIFO顺序
multiCmd *commands;
// 已入队命令计数
int count;
} multiState;
事务队列是一个multiCmd类型的数组，数组中的每个multiCmd结构都保存了一个已入队命令的相关信息，包括指向命令实现函数的指针、命令的参数，以及参数的数量:
typedef struct multiCmd{
// 参数
robj **argv;
// 参数数量
int argc;
// 命令指针
struct redisCommand *cmd;
} multiCmd;
事务队列以先进先出（FIFO）的方式保存入队的命令，较先入队的命令会被放到数组的前面，而较后入队的命令则会被放到数组的后面。
以下列操作为例，我们分析一下服务器执行不同命令时，事务的状态。
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set "name" "Shiwk Common Lisp"
QUEUED
127.0.0.1:6379> get "name"
QUEUED
127.0.0.1:6379> set "author" "shiwk"
QUEUED
127.0.0.1:6379> get "author"
QUEUED
分析：
最先入队的SET命令被放在了事务队列的索引0位置上。
第二入队的GET命令被放在了事务队列的索引1位置上。
第三入队的另一个SET命令被放在了事务队列的索引2位置上。最后入队的另一个GET命令被放在了事务队列的索引3位置上。
（3）事务执行
当一个处于事务状态的客户端向服务器发送EXEC命令时，这个EXEC命令将立即被服务器执行。服务器会遍历这个客户端的事务队列，执行队列中保存的所有命令，最后将执行命令所得的结果全部返回给客户端。
举例说明：
set "name""Shiwk Common Lisp"
接着执行命令:
get "name"
之后执行命令:
set "author" "shiwk"
再之后执行命令:
get "author"
最后，服务器会将执行这四个命令所得的回复返回给客户端:
127.0.0.1> exec
1)OK
2)"Shiwk Common Lisp"
3)OK
4)"shiwk"
exec命令的实现原理可以用以下伪代码来描述:
def EXEC()；
//创建空白的回复队列
reply_queue =[ ]
//遍历事务队列中的每个项
//读取命令的参数,参数的个数，以及要执行的命令
for argv,argc, cmd in client.mstate.commands:
#执行命令，并取得命令的返回值
reply = execute_command (cmd, argv, argc)
#将返回值追加到回复队列末尾
reply_queue.append (reply)
//移除REDIS_MULT工标识,让客户端回到非事务状态client.flags &=~REDIS_MULTI
//清空客户端的事务状态，包括:#1)清零入队命令计数器
//2)释放事务队列
client.mstate.count = o
release_transaction_queue (client.mstate.commands)
//将事务的执行结果返回给客户端
send_reply_to_client (client, reply_queue)
1.2watch命令的实现
WATCH命令是一个乐观锁(optimistic locking)，它可以在EXEC命令执行之前，监视任意数量的数据库键，并在EXEC命令执行时，检查被监视的键是否至少有一个已经被修改过了，如果是的话，服务器将拒绝执行事务，并向客户端返回代表事务执行失败的空回复。
我们通过举例，来分析事务执行失败的原因。
c10086:6379> watch "name"
OK
c10086:6379> multi
OK
c10086:6379> set "name" "guigu"
QUEUED
c10086:6379> exec
(nil)
错误原因分析：
| 时间 | 客户端A | 客户端B |
| T1 | watch "name" | |
| T2 | multi | |
| T3 | set "name" "guigu" | |
| T4 | set "name" "ss" | |
| T5 | exec |
在时间T4，客户端B修改了"name"键的值，当客户端A在T5执行EXEC命令时,服务器会发现WATCH监视的键"name"已经被修改，因此服务器拒绝执行客户端A的事务,并向客户端A返回空回复。
1.3watch命令监控数据库键
每个Redis数据库都保存着一个watched keys字典，这个字典的键是某个被WATCH命令监视的数据库键，而字典的值则是一个链表，链表中记录了所有监视相应数据库键的客户端:
typedef struct redisdb{
...
// 正在被Watch命令监控的键
dict *watched_keys；
// ...
} redisdb;
通过watched_keys字典，服务器可以清楚地知道哪些数据库键正在被监视，以及哪些客户端正在监视这些数据库键。
watched_keys字典示例:
从这个watched_keys字典中可以看出
客户端c1和c2正在监视键"name"。
客户端c3正在监视键"age"。
客户端c2和c4正在监视键"address"。
通过执行WATCH命令，客户端可以在watched_keys字典中与被监视的键进行关联。
举个例子，如果当前客户端为c10086，那么客户端执行以下WATCH命令之后:
redis> WATCH "name" "age"
OK
watched_keys字典中数据将执行更新操作，其中用虚线包围的两个c10086节点就是由刚刚执行的WATCH命令添加到字典中的。
图解分析：
1.4watch监控机制的触发
所有对数据库进行修改的命令，比如SET、LPUSH、SADD、ZREM、DEL、FLUSHDB等等，在执行之后都会调用multi.c/touchwatchKey函数对watched_keys字典进行检查，查看是否有客户端正在监视刚刚被命令修改过的数据库键，如果有的话，那么touchwatchKey()函数会将监视被修改键的客户端的REDIS_DIRTY_CAS标识打开，表示该客户端的事务安全性已经被破坏。
touchwatchKey函数的定义可以用以下伪代码来描述:
def touchwatchKey(db,key) :
#如果键key存在于数据库的watched_keys字典中
#那么说明至少有一个客户端在监视这个key
if key in db . watched_keys :
#遍历所有监视键key的客户端
for client in db . watched_keys [ key] :
#打开标识
client.flags l=REDIS_DIRTY_CAS
举例说明：
如果键"name”被修改，那么c1、c2、c10086三个客户端的REDIS_DIRTY_CAS标识将被打开。
如果键"age"被修改，那么c3和c10086两个客户端的REDIS_DIRTY_CAS标识将被打开。
如果键"address"被修改，那么c2和c4两个客户端的REDIS_DIRTY_CAS标识将被打开。
1.5判断事务是否安全
当服务器接收到一个客户端发来的EXEC命令时，服务器会根据这个客户端是否打开了REDIS_DIRTY_CAS标识来决定是否执行事务：
如果客户端的REDIS_DIRTY_CAS标识已经被打开，那么说明客户端所监视的键当中，至少有一个键已经被修改过了，在这种情况下，客户端提交的事务已经不再安全，所以服务器会拒绝执行客户端提交的事务。
如果客户端的REDIS_DIRTY_CAS标识没有被打开，那么说明客户端监视的所有键都没有被修改过（或者客户端没有监视任何键)，事务仍然是安全的，服务器将执行客户端提交的这个事务。
1.6一个完整的Watch事务执行过程
假设当前客户端为c10086，而数据库watched_keys字典的当前状态如下图所示：
当c10086客户端执行一下watch命令后：
c10086>watch "name"
OK
watched_keys字典状态更新如下：
接下来，客户端c10086继续向服务器发送MULTI命令，并将一个SET命令放入事务队列:
c10086>multi
OK
c10086>set "name" "guigu"
QUEUED
就在这时，另一个客户端c999向服务器发送了一条SET命令，将"name"键的值设置成了"john" :
c999>set "name" "john"
OK
c999执行的这个SET命令会导致正在监视"name"键的所有客户端的REDIS.DIRTY_CAS标识被打开，其中包括客户端c10086。
之后，当c10086向服务器发送EXEC命令时候，因为c10086的REDIS_DIRTY_CAS标志已经被打开，所以服务器将拒绝执行它提交的事务:
c10086>exec
(nil)
二、事务的ACID性质
在传统的关系式数据库中，常常用ACID性质来检验事务功能的可靠性和安全性。在Redis中，事务总是具有原子性(Atomicity )、一致性(Consistency）和隔离性( Isolation )，并且当Redis运行在某种特定的持久化模式下时，事务也具有耐久性(Durability )。
2.1原子性
事务具有原子性指的是，数据库将事务中的多个操作当作一个整体来执行，服务器要么就执行事务中的所有操作，要么就一个操作也不执行。
对于Redis 的事务功能来说，事务队列中的命令要么就全部都执行，要么就一个都不执行,因此，Redis 的事务是具有原子性的。
举例说明，一个成功执行的事务，事务中的所有命令都会被执行：
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set msg "hello"
QUEUED
127.0.0.1:6379> get msg
QUEUED
127.0.0.1:6379> exec
1) OK
2) "hello"
与此相反，在展示一个执行失败的事务，这个事务因为命令入队出错而被服务器拒绝执行，事务中的所有命令都不会被执行:
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set msg "hello"
QUEUED
127.0.0.1:6379> get
(error)ERR wrong number of arguments for 'get' command
127.0.0.1:6379> get msg
QUEUED
127.0.0.1:6379>exec
(error) EXECABORT Transaction discarded because of previous errors.
Redis 的事务和传统的关系型数据库事务的最大区别在于，Redis不支持事务回滚机制(rollback)，即使事务队列中的某个命令在执行期间出现了错误，整个事务也会继续执行下去．直到将事务队列中的所有命令都执行完毕为止。
2.2一致性
事务具有一致性指的是，如果数据库在执行事务之前是一致的，那么在事务执行之后,无论事务是否执行成功，数据库也应该仍然是一致的。
“一致”指的是数据符合数据库本身的定义和要求，没有包含非法或者无效的错误数据。Redis通过谨慎的错误检测和简单的设计来保证事务的一致性。
以下三个小节将分别介绍三个Redis事务可能出错的地方，并说明Redis是如何妥善地处理这些错误，从而确保事务的一致性的。
（1）入队错误
如果一个事务在入队命令的过程中，出现了命令不存在，或者命令的格式不正确等情况,那么Redis将拒绝执行这个事务。
在下面示例中，因为客户端尝试向事务入队一个不存在的命令YAH0000，所以客户端提交的事务会被服务器拒绝执行:
127.0.0.1:6379> multi
OK
127.0.0.1:6379>SET msg "hello"
QUEUED
127.0.0.1:6379> YAHOOOO
(error) ERR unknown command 'YAHOOOO'
127.0.0.1:6379>get msg
QUEUED
127.0.0.1:6379>exec
(error)EXECABORT Transaction discarded because of previous errors.
因为服务器会拒绝执行人队过程中出现错误的事务，所以Redis事务的一致性不会被带有入队错误的事务影响。
（2）执行错误
除了入队时可能发生错误以外，事务还可能在执行的过程中发生错误。关于这种错误有两个需要说明的地方:
执行过程中发生的错误都是一些不能在入队时被服务器发现的错误，这些错误只会在命令实际执行时被触发。即使在事务的执行过程中发生了错误，服务器也不会中断事务的执行，它会继续执行事务中余下的其他命令，并且已执行的命令（包括执行命令所产生的结果)不会被出错的命令影响。
对数据库键执行了错误类型的操作是事务执行期间最常见的错误之一。
在下面例子中，我们首先用set命令将键"msg"设置成了一个字符串键，然后在事务里面尝试对"msg"键执行只能用于列表键的RPUSH命令，这将引发一个错误，并且这种错误只能在事务执行（也即是命令执行)期间被发现:
127.0.0.1:6379> set msg "hello"
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379>sadd fruit "apple" "banana" "cherry"
QUEUED
127.0.0.1:6379>rpush msg "good bye" "bye bye"
QUEUED
127.0.0.1:6379>sadd alphabet "a" "b""c"
QUEUED
127.0.0.1:6379>EXEC
1)(integer) 3
2) (error) WRONGTYPE 0peration against a key holding the wrong kind of value
3)(integer) 3
因为在事务执行的过程中，出错的命令会被服务器识别出来，并进行相应的错误处理，所以这些出错命令不会对数据库做任何修改，也不会对事务的一致性产生任何影响。
（3）服务器停机
如果Redis服务器在执行事务的过程中停机，那么根据服务器所使用的持久化模式，可能有以下情况出现:
如果服务器运行在无持久化的内存模式下，那么重启之后的数据库将是空白的，因此数据总是一致的。
如果服务器运行在RDB模式下，那么在事务中途停机不会导致不一致性，因为服务器可以根据现有的RDB文件来恢复数据，从而将数据库还原到一个一致的状态。如果找不到可供使用的RDB文件，那么重启之后的数据库将是空白的，而空白数据库总是一致的。
如果服务器运行在AOF模式下，那么在事务中途停机不会导致不一致性，因为服务器可以根据现有的AOF文件来恢复数据，从而将数据库还原到一个一致的状态。如果找不到可供使用的AOF文件，那么重启之后的数据库将是空白的，而空白数据库总是一致的。
综上所述，无论Redis服务器运行在哪种持久化模式下，事务执行中途发生的停机都不会影响数据库的一致性。
2.3隔离性
事务的隔离性指的是，即使数据库中有多个事务并发地执行，各个事务之间也不会互相影响，并且在并发状态下执行的事务和串行执行的事务产生的结果完全相同。
因为Redis使用单线程的方式来执行事务（以及事务队列中的命令)，并且服务器保证，在执行事务期间不会对事务进行中断，因此，Redis的事务总是以串行的方式运行的，并且事务也总是具有隔离性的。
2.4耐久性
事务的耐久性指的是，当一个事务执行完毕时，执行这个事务所得的结果已经被保存到永久性存储介质（比如硬盘）里面了，即使服务器在事务执行完毕之后停机，执行事务所得的结果也不会丢失。
因为Redis的事务不过是简单地用队列包裹起了一组Redis命令，Redis并没有为事务提供任何额外的持久化功能，所以Redis事务的耐久性由Redis所使用的持久化模式决定:
当服务器在无持久化的内存模式下运作时，事务不具有耐久性:一旦服务器停机，包括事务数据在内的所有服务器数据都将丢失。
当服务器在RDB持久化模式下运作时，服务器只会在特定的保存条件被满足时，才会执行BGSAVE命令，对数据库进行保存操作，并且异步执行的BGSAVE不能保证事务数据被第一时间保存到硬盘里面，因此RDB持久化模式下的事务也不具有耐久性。
当服务器运行在AOF持久化模式下，并且appendfsync选项的值为always时，程序总会在执行命令之后调用同步(sync）函数，将命令数据真正地保存到硬盘里面，因此这种配置下的事务是具有耐久性的。
当服务器运行在AOF持久化模式下，并且appendfsync选项的值为everysec时，程序会每秒同步一次命令数据到硬盘。因为停机可能会恰好发生在等待同步的那一秒钟之内，这可能会造成事务数据丢失，所以这种配置下的事务不具有耐久性。
不论Redis在什么模式下运作，在一个事务的最后加上SAVE命令总可以保证事务的耐久性:
127.0.0.1:6379>MULTI
OK
127.0.0.1:6379>SET msg "hello"
QUEUED
127.0.0.1:6379> SAVE
QUEUED
127.0.0.1:6379> EXEC
1)OK
2)OK
不过因为这种做法的效率太低，所以并不具有实用性。
总结
事务提供了一种将多个命令打包，然后一次性、有序地执行的机制。
多个命令会被入队到事务队列中，然后按先进先出（FIFO)的顺序执行。
事务在执行过程中不会被中断，当事务队列中的所有命令都被执行完毕之后，事务才会结束。
带有WATCH命令的事务会将客户端和被监视的键在数据库的watched_keys字典中进行关联，当键被修改时，程序会将所有监视被修改键的客户端的REDIS_DIRTY_CAS标志打开。
只有在客户端的REDIS_DIRTY_CAS标志未被打开时，服务器才会执行客户端提交的事务，否则的话，服务器将拒绝执行客户端提交的事务。
Redis 的事务总是具有ACID中的原子性、一致性和隔离性，当服务器运行在AOF持久化模式下，并且 appendfsync选项的值为always时，事务也具有耐久性。