Redis通过MULTI、EXEC、WATCH等命令来实现事务( transaction)功能。事务提供了一种将多个命令请求打包，然后- -次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求。
1.redis事务的执行流程
在讲解事务前先简单介绍一下，有关事务的两个命令
- multi：标记一个事务块的开始。 随后的指令将在执行EXEC时作为一个原子执行。
MULTI
- exec：执行事务中所有在排队等待的指令并将链接状态恢复到正常 当使用WATCH 时，只有当被监视的键没有被修改，且允许检查设定机制时，EXEC会被执行
EXEC
故redis事务的执行流程是：先使用multi命令开启事务模式，然后输入要执行的代码。输入结束后，输入exec命令，执行刚才输入的命令：
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set a 1
QUEUED
127.0.0.1:6379> set b 2
QUEUED
127.0.0.1:6379> get a
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) "1"
127.0.0.1:6379>
在执行exec指令后，redis会把每一天输入指令的执行结果输出到屏幕上。
一个事务从开始到结束通常会经历以下三个阶段:
1)事务开始。
2)命令人队。
3)事务执行。
2.事务开始
执行multi命令表示事务开始；
MULTI命令可以将执行该命令的客户端从非事务状态切换至事务状态，这- -切换是通
过在客户端状态的flags属性中打开REDIS_ MULTI标识来完成的。
3.命令入队
在非事务的情况下，向redis客户端输入的命令，会被立即执行，而在事务的情况下，指令的执行会有所不同：
- 如果客户端发送的命令为EXEC、DISCARD、WATCH、MULTI四个命令的其中一个，那么服务器立即执行这个命令。
- 与此相反，如果客户端发送的命令是EXEC、DISCARD、WATCH、MULTI四个命令以外的其他命令，那么服务器并不立即执行这个命令，而是将这个命令放入一个事务队列里面，然后向客户端返回QUEUED回复。
事务队列
因为输入进redis客户端的命令不会立即执行，所以当我们输入命令后，redis会把我们输入的命令都放入一个数组队列中（即以队列的形式来安排数据的添加和删除，以数组来存储数据）。如执行以下命令：
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET "name" "Practical Common Li sp"
QUEUED
127.0.0.1:6379> GET "name"
QUEUED
127.0.0.1:6379> SET "author" "Peter Seibel "
QUEUED
127.0.0.1:6379> GET "author"
QUEUED
那么在redis中这些命令会被存入一个数组队列：
4.命令的执行
当执行EXEC命令后，redis会遍历命令入队过程中的数组，按照先后顺序依次执行命令，并把命令执行的结果，返回显示在屏幕上：
127.0.0.1:6379> exec
1) OK
2) Practical Common Li sp3)
3） OK
4) "Peter Seibel "
5.watch命令
WATCH命令是一个 乐观锁( optimistic locking),它可以在EXEC命令执行之前，监视任意数量的数据库键，并在EXEC命令执行时，检查被监视的键是否至少有-一个已经被修改过了，如果是的话，服务器将拒绝执行事务，并向客户端返回代表事务执行失败的空回复。
使用 check-and-set 操作实现乐观锁
WATCH 命令可以为 Redis 事务提供 check-and-set （CAS）行为。
被 WATCH 的键会被监视，并会发觉这些键是否被改动过了。 如果有至少一个被监视的键在 EXEC 执行之前被修改了， 那么整个事务都会被取消， EXEC 返回nil-reply来表示事务已经失败。
举个例子， 假设我们需要原子性地为某个值进行增 1 操作（假设 INCR 不存在）。
首先我们可能会这样做：
val = GET mykey
val = val + 1
SET mykey $val
上面的这个实现在只有一个客户端的时候可以执行得很好。 但是， 当多个客户端同时对同一个键进行这样的操作时， 就会产生竞争条件。举个例子， 如果客户端 A 和 B 都读取了键原来的值， 比如 10 ， 那么两个客户端都会将键的值设为 11 ， 但正确的结果应该是 12 才对。
有了 WATCH ， 我们就可以轻松地解决这类问题了：
WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC
使用上面的代码， 如果在 WATCH 执行之后， EXEC 执行之前， 有其他客户端修改了 mykey 的值， 那么当前客户端的事务就会失败。 程序需要做的， 就是不断重试这个操作， 直到没有发生碰撞为止。
这种形式的锁被称作乐观锁， 它是一种非常强大的锁机制。 并且因为大多数情况下， 不同的客户端会访问不同的键， 碰撞的情况一般都很少， 所以通常并不需要进行重试。
6.放弃事务（DISCARD）
- discard：刷新一个事务中所有在排队等待的指令，并且将连接状态恢复到正常。如果已使用WATCH，DISCARD将释放所有被WATCH的key。
7.事务的ACID属性
在Redis中，事务总是具有原子性(Atomicity)、一致性(Consistency)和隔离性( Isolation),并且当Redis运行在某种特定的持久化模式下时，事务也具有耐久性( Durability )。
1.原子性
事务具有原子性指的是，数据库将事务中的多个操作当作-一个整体来执行,服务器要么就执行事务中的所有操作，要么就一个操作也不执行。
对于Redis的事务功能来说，事务队列中的命令要么就全部都执行，要么就-一个都不执行，因此，Redis 的事务是具有原子性的。
redis不支持回滚
redis与传统关系型最大的区别是，redis不支持事务回滚，即如果在exec执行命令的过程中，某条指令出现错误，redis会继续执行后面的语句，而不会回滚到事务开启前的状态。即执行过程中的错误不影响，事务的执行：
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set w a a
QUEUED
127.0.0.1:6379> set hh 12
QUEUED
127.0.0.1:6379> get hh
QUEUED
127.0.0.1:6379> exec
1) (error) ERR syntax error
2) OK
3) "12"
例子中第一条指令在执行时发生错误，但依旧可以执行后面的语句。
redis不支持事务回滚的原因：
Redis的作者在事务功能的文档中解释说，不支持事务回滚是因为这种复杂的功能和Redis追求简单高效的设计主旨不相符，并且他认为，Redis事务的执行时错误通常都是编程错误产生的，这种错误通常只会出现在开发环境中，而很少会在实际的生产环境中出现，所以他认为没有必要为Redis开发事务回滚功能。
有种观点认为 Redis 处理事务的做法会产生 bug ， 然而需要注意的是， 在通常情况下， 回滚并不能解决编程错误带来的问题。 举个例子， 如果你本来想通过 INCR 命令将键的值加上 1 ， 却不小心加上了 2 ， 又或者对错误类型的键执行了 INCR ， 回滚是没有办法处理这些情况的。
2.一致性
事务具有一致性指的是，如果数据库在执行事务之前是一致的，那么在事务执行之后,无论事务是否执行成功，数据库也应该仍然是一致的。
“一致”指的是数据符合数据库本身的定义和要求，没有包含非法或者无效的错误数据。Redis通过谨慎的错误检测和简单的设计来保证事务的一致性，以下三个小节将分别介绍三个Redis事务可能出错的地方，并说明Redis是如何妥善地处理这些错误，从而确保事务的一致性的。
1.入队错误
如果redis在开启事务后的输入指令时，输入的某一指令出现格式错误，或指令不存在，那么redis会拒绝执行事务。此时没有数据的输入所以数据库中的数据是一致的。
Redis 2.6.5以前的入队错误处理
根据文档记录，在Redis 2.6.5以前的版本，即使有命令在入队过程中发生了错误，事务一样可以执行，不过被执行的命令只包括那些正确入队的命令。以下这段代码是在Redis 2.6.4版本上测试的，可以看到，事务可以正常执行，但只有成功入队的SET命令和GET命令被执行了，而错误的YAH0000则被忽略了:
redis> MULTI
OK
redis> SET msg "he11o"
QUEUED
redis> YAH000O
(error) ERR unknown command ' YAHO000'
redis> GET msg
QUEUED
redis> EXEC
- 0K
- "hello"
2.执行错误
在讨论redis不支持事务回滚时，就讨论过该问题，因为错误的指令不会存入数据库，而正确的指令都存入了数据库，所以执行错误也不会影响redis的一致性。
3.服务器停机
服务器出现停机，那么如果没有开启rdb或aof那么数据库所有数据都会消失，不影响一致性，而有rdb或aof时会根据这两个把数据再次装入数据库，所以这种情况下redis的数据也是一致的。
3.隔离性
redis是单线程的，无论并发量多大，进入redis后，都是串行执行，所以并发情况和串行情况下在开启事务后，也是一样。
因为Redis使用单线程的方式来执行事务(以及事务队列中的命令),并且服务器保证,在执行事务期间不会对事务进行中断，因此，Redis的事务总是以串行的方式运行的，并且事务也总是具有隔离性的。
4.持久性
事务的耐久性指的是，当一个事务执行完毕时，执行这个事务所得的结果已经被保存到永久性存储介质(比如硬盘)里面了，即使服务器在事务执行完毕之后停机，执行事务所得的结果也不会丢失。
因为Redis的事务不过是简单地用队列包裹起了--组Redis命令，Redis并没有为事务提供任何额外的持久化功能，所以Redis事务的耐久性由Redis所使用的持久化模式决定:
当服务器在无持久化的内存模式下运作时，事务不具有耐久性:一旦服务器停机，包括事务数据在内的所有服务器数据都将丢失。
当服务器在RDB持久化模式下运作时，服务器只会在特定的保存条件被满足时，才会执行BGSAVE命令，对数据库进行保存操作，并且异步执行的BGSAVE不能保证事务数据被第一时间保存到硬盘里面，因此RDB持久化模式下的事务也不具有耐久性。
当服务器运行在AOF持久化模式下，并且appendfsync选项的值为always时,程序总会在执行命令之后调用同步(sync) 函数，将命令数据真正地保存到硬盘里面，因此这种配置下的事务是具有耐久性的。
当服务器运行在AOF持久化模式下，并且appendfsync选项的值为everysec时，程序会每秒同步--次命令数据到硬盘。因为停机可能会恰好发生在等待同步的那一秒钟之内，这可能会造成事务数据丢失，所以这种配置下的事务不具有耐久性。
文章部分参考：
《redis设计与实现(第二版)》
redis中文官网：http://redis.cn/topics/transactions.html