redis 持久化 镜像

redis是原子的吗？__get，set接口；事物：mutil开始提交指令到队列，exec执行提交的指令,discard丢弃mutil后提交的命令；命令序列原子性：watch key，mutil，exec执行指令  

2013-04-08 18:13:17|  分类： key_value|举报|字号 订阅

一、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，因为冲突不太可能。(不过要看自己的应用场景，如果这种冲突很大，那就需要想其它办法将指令串行起来)