一、get,set接口:
二、mutil总是返回OK,然后调用get,set写数据,这些指令会被提交到队列,exec执行提交的指令:
1、Redis事物通过MULTI命令开始。 这条命令总是返回OK。
2、然后用户可以执行多条指令,redis不会马上执行这些指令,还只是放入到队列中。
3、当执行exec指令时,所有的指令执行。
4、调用discard指令,将会flush事物队列,并且退出事物。
如下:
redis 127.0.0.1:6379> multi
OK
redis 127.0.0.1:6379> set foo 1
QUEUED
redis 127.0.0.1:6379> incr foo
QUEUED
redis 127.0.0.1:6379> incr foo
QUEUED
redis 127.0.0.1:6379> exec
1) OK
2) (integer) 2
3) (integer) 3
从以上会话中能看到multi命令返回的回复是一个数组,每个元素即是事物中每条指令的回复,并且跟指令发布的顺序一样。当redis连接在multi请求下,所有的命令回复都是queued,除非这条指令的语句法不正确。而一些指令语法正确,但执行阶段出错也是允许的。
如以下:
redis 127.0.0.1:6379> multi
OK
redis 127.0.0.1:6379> set t 13
QUEUED
redis 127.0.0.1:6379> lpop t
QUEUED
redis 127.0.0.1:6379> exec
1) OK
2) (error) ERR Operation against a keyholding the wrong kind of value
对于这种err,需要客户端给予合理的提示。
需要注意的是,所有在队列中的指令都会被执行,redis不会终止指令的执行(事物中有指令失败事物不会终止在这条失败的指令上)。
三、mutil总是返回OK,然后调用get,set写数据,这些指令会被提交到队列,discard取消命令队列,不执行事物:
Discard为取消命令队列。可以终断一个事物。不会有命令会被执行,并且连接的状态是正常的。
如:
> SET foo 1
OK
> MULTI
OK
> INCR foo
QUEUED
> DISCARD
OK
> GET foo
"1"
四、redis的optimistic locking using check-and-set(乐观锁),实现get,set命令序列数据的原子性:
watch指令在redis事物中提供了CAS的行为。
为了检测被watch的keys在是否有多个clients改变时引起冲突,这些keys将会被监控。
如果至少有一个watch的key在执行exec命令前被修改,整个事物将会被终止,并且执行exec会得到null的回复。
例如:一个key自增长(假设redis不提供incr的功能)
val = GET mykey
val = val + 1
SET mykey $val
以上指令执行,如果是单一的client,整个操作是没问题的。如果多个client在同一时间操作。如client A与 client B读取了老的值,假如是10,这个值在两个client将会被增长到11,最后set这个key值时,这个key最终是11还不是12.
watch能够很好的处理这种问题:
WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC
使用以上代码,如果在执行watch与exec指令这段时间里有其它客户端修改此key值,此事物将执行失败。以上形式的锁被称为乐观锁。在大多数使用场合中,多并发将会处理不能的keys,因为冲突不太可能。(不过要看自己的应用场景,如果这种冲突很大,那就需要想其它办法将指令串行起来)