说到事务我们都知道，一个事务中的命令要么都执行，要么都不执行。
先看看 Redis 的一个事务：
redis 127.0.0.1:6379> MULTI
OK
redis 127.0.0.1:6379> SADD "user:1:following" 2
QUEUED
redis 127.0.0.1:6379> SADD "user:1:following" 1
QUEUED
redis 127.0.0.1:6379> EXEC
1) (integer) 1
2) (integer) 1
redis 127.0.0.1:6379>
首先使用MULTI命令告诉Redis，一下命令属于同一个事务，先暂时存起来不要执行，Redis 返回 OK；
后面发的命令返回QUEUED表示这两条命令已经进入等待执行的事务队列中 ；
直到使用 EXEC 命令，将等待执行的事务队列中的所有命令按照发送顺序依次执行。
Redis事务
Redis保证一个事务中的所有命令要么都执行，要么都不执行。如果在发送EXEC命令前 客户端断线了，则 Redis 会清空事务队列，事务中的所有命令都不会执行。而一旦客户端发 送了EXEC命令，所有的命令就都会被执行，即使此后客户端断线也没关系，因为Redis中已 经记录了所有要执行的命令。
Redis 的事务还能保证一个事务内的命令依次执行而不被其他命令插入。试想客户端A需要执行几条命令，同时客户端B发送了一条命令，如果不使用事务，则客户端B的命令可能会插入到客户端A的几条命令中执行。如果不希望发生这种情况，也可以使用事务。
错误处理
使用事务时可能会遇上以下两种错误：
- 事务在执行
EXEC之前，入队的命令可能会出错。 - 命令可能在
EXEC调用之后失败。
如果一个事务中的某个命令执行之前出错，则服务器会记录失败情况，在调用 EXEC 时，会拒绝执行并自动放弃这个事务。
至于那些在 EXEC 命令执行之后所产生的错误， 并没有对它们进行特别处理： 即使事务中有某个/某些命令在执行时产生了错误， 事务中的其他命令仍然会继续执行。
【提示】Redis 不支持回滚（roll back）
以下是这种做法的优点：
- Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。
- 因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。
有种观点认为 Redis 处理事务的做法会产生 bug ， 然而需要注意的是， 在通常情况下， 回滚并不能解决编程错误带来的问题。
鉴于没有任何机制能避免程序员自己造成的错误， 并且这类错误通常不会在生产环境中出现， 所以 Redis 选择了更简单、更快速的无回滚方式来处理事务。
WATCH 命令
在一个事务中只有当所有命令都依次执行完后才能得到每个结果的返回值。
可是有些情况下需要先获得一条命令的返回值，然后再根据这个值执行下一条命令。这时候就会因为某条命令不能正常执行而导致整个事务失败。
为解决这个问题，就要用到 WATCH 。
WATCH 命令可以监控一个 或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行。监控一直持续到 EXEC 命令。
如下：
redis 127.0.0.1:6379> SET key 1
OK
redis 127.0.0.1:6379> WATCH key
OK
redis 127.0.0.1:6379> set key 2
OK
redis 127.0.0.1:6379> MULTI
OK
redis 127.0.0.1:6379> SET key 3
QUEUED
redis 127.0.0.1:6379> EXEC
(nil)
redis 127.0.0.1:6379> GET key
"2"
redis 127.0.0.1:6379>
上例中在执行 WATCH命令后、事务执行前修改了key的值（即 SET key 2），所以最后事务中的命令 SET key 3 没有执行，EXEC命令返回空结果。
【提示】
由于WATCH命令的作用只是当被监控的键值被修改后阻止之后一个事务的执行， 而不能保证其他客户端不修改这一键值，所以我们需要在EXEC执行失败后重新执行整个函 数。
执行 EXEC 命令后会取消对所有键的监控，如果不想执行事务中的命令也可以使用 UNWATCH命令来取消监控。
命令小总结
| key | 含义 |
|---|---|
| MULTI | 事务开始的命令 |
| EXEC | 执行事务中的命令 |
| WATCH key [key ...] | 监控 key 值，有变化则不执行事务 |
| UNWATCH | 取消监控 |