multi、exec、discard、watch是Redis中事务的基础。他们允许一组命令在一步内执行完成，并且可以实现如下特点：
1）在事务中的一组命令被序列化并按照顺序追个执行。在事务执行过程中不会出现穿插执行其他客户端请求的问题。这保证了一组命令可以像一个单独的命令一样被执行。
2）事务中的命令要么都被执行要么都不被执行，所以它是原子性的。在事务中exec命令触发事务中所有命令的执行，所以如果客户端在调用multi命令之前丢失了与服务器端的连接，事务中的任何命令都不会被执行，相反，如果exec被调用了，那么事务中所有的命令都将被执行。当设置了appendonly属性为yes时，Redis将会产生一个单独的系统调用将事务写入硬盘中。但是如果Redis服务器突然宕机或者Redis进程被系统管理员杀掉，那么可能会只有一部分操作会被记住，那么Redis在重启的时候检测这种情况，并报告错误并退出。使用redis-check-aof工具可能修复aof文件，它将删除这部分事务操作，Redis就可以正常重启了。
Redis 2.2版本后，除了上面两点外，增加了乐观锁，它非常像check-and-set（CAS）操作。稍后将会介绍这部分内容。
使用范围
Redis事务以命令multi开始，命令总是以ok做响应。这个时候用户可以列出很多的命令，此时Redis将命令放入队列中而不执行它，直到exec命令被调用，所有的命令才会被执行。调用discard命令将会清空事务队列并退出事务。如下是一个简单的使用：
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incr foo
QUEUED
127.0.0.1:6379> incr bar
QUEUED
127.0.0.1:6379> exec
1) (integer) 1
2) (integer) 1
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incr foo
QUEUED
127.0.0.1:6379> incr bar
QUEUED
127.0.0.1:6379> discard
OK
127.0.0.1:6379> get foo
"1"
127.0.0.1:6379> get bar
"1"
事务中的错误
在事务中可能发生两种类型的命令错误：
1）命令排队失败，在exec调用之前发生错误。如命令语法错误或者处于一种临街状态如超出了内存状态。
2）发生在exec调用之后。如我们执行了一个操作赋值给一个key以错误的类型。如调用一个list赋值操作但是给出一个string的值。
第一类错误是客户端习惯能检测到的。这类错误发生在exec调用之前，通过检查队列中命令的返回值：若命令返回QUEUE，则该命令排队成功，否则Redis将会返回一个错误。若在排队过程中发生错误，客户端将会终止事务并清除队列。
但是在Redis 2.6.5版本之前，客户端将会执行已经排队成功的命令的子集而忽略发生错误的命令。所以新的行为使得很容易通过管道使用事务，所以整个整个的事务将会立刻被发送，同时读取所有的响应。
发生在exec之后的错误并没有做特殊的处理：所有的未发生错误的命令都会被执行，即使在事务中有部分发生错误。
这在协议级别更加的清晰。在下面的例子中将会有一个命令执行失败即使它的语法是正确的：
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
MULTI
+OK
SET a 3
abc
+QUEUED
LPOP a
+QUEUED
EXEC
*2
+OK
-ERR Operation against a key holding the wrong kind of value
接下来是一个展示发生在调用exec之前的错误：
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incr a b c
(error) ERR wrong number of arguments for 'incr' command
通过以上两个例子可以看出，Redis对命令语法的检测只是简单的形式上的、惰性的，只有在命令被执行的时候才会真正的显示出来。
Redis为什么不支持回滚
如果了解过关系型数据库，对于Redis事务发生错误时不回滚的表现会感到非常奇怪。
如下是一些好的观点：
1）Redis只有发生语法错误或者key的相关才做违反了值得数据类型的时候，才会发生错误。也就是说发生在Redis中的命令的失败是一种编程错误、是一种可以在开发过程中发现并修正的错误。
2）由于Redis不需要回滚，所以内部操作是非常简单快速的。
一个关于Redis观点的论据是，发生错误后进行即使按照通常地回滚也不能修复导致这种结果的编程错误。举个例子：要将一个key的值增加2，但是却错误的增加了1或者干脆将key搞错了，在这种情况下，即使回滚也无法避免这种问题，因为这是编码错误，没有办法挽救程序员的编码错误，而且这种错误不应该被带进产品中，所以Redis采取了简单快捷的方法处理，那就是不支持发生错误的回滚。
丢弃事务中的排队队列
discard命令被用来终止事务。一旦调用该命令，事务中的命令都不会被执行，连接状态将回到正常状态。
127.0.0.1:6379> set foo 1
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incr foo
QUEUED
127.0.0.1:6379> discard
OK
127.0.0.1:6379> get foo
"1"
命令watch被用来提供一个CAS（check-and-set）行为給事务。
watch会监控keys的变化。若在调用exec之前，至少有一个添加了watch的key被修改，整个事务将会被终止，并且exec返回一个空响应通知以表明事务失败。举个例子，假设我们想原子性的实现将key的value增加1（假设Redis中没有incr命令）。
第一次尝试可能如下：
val=get mykey
val=val+1
set mykey $val
watch mykey
val=get mykey
val=val+1
multi
set key $value
exec
关于watch的解释
watch是一个命令，它将exec命令编程一个条件语句：只有在我们watch的keys没有一个被修改，Redis才会执行事务，否则事务根本不会发生。例外情况是，这个key设置了过期时间并且已经到了时间，那么对这个key的watch将失效，exec是会被执行的。
watch可以使用多次。watch发生作用的是从调用该命令开始直到exec被执行。也可以使用一个watch监控多个命令。
调用exec之后，所有的keys的watch状态失效，处于unwatched状态，在不管事务成功与否的情况下。当客户端失去连接后，所有的keys都会变成unwatched状态。
unwatch命令可以取消对keys的watch监控。这在我们使用乐观锁锁住少数keys的情况下非常有用，因为我们很可能想通过事务修改这些keys，但是读取了它们的values后我们不想这么做了。
使用watch命令实现zpop
有一个解释watch可以方便的创造一个原子操作的很好例子是zpop的实现。zpop定义为原子性地从sorted sets中移除其score最小的元素。下面是一个实现：
watch zset
element=zrange zset 0 0
multi
zrem zset element
exec
Redis脚本化和事务
Redis 脚本是定义好的事务性的，支持原子操作。所以可以用事务做的一切工作都可以用脚本实现，而且又是在于，通常脚本更加地简介快速。
脚本化和事务看似是一个重复操作，其实不然。首先，Redis脚本是Redis 2.6才有的特性而事务一开始就存在。但是不像移除事务的原因是它具有很好的语义并且在没有使用Redis脚本的情况下也可以工作的很好，尤其事务的实现复杂性是最小的。
或许在不久的将来，我们将会看到用户只是使用脚本而不再青睐事务，这是我们也将反对事务转而支持脚本化，从而将事务从Redis中移除。
扫一扫
228
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
