Redis的事务基于四个命令:
- MULTI
- EXEC
- DISCARD
- WATCH
创建事务
Redis的事务从一个MULTI命令开始,MULTI总会命令返回"ok"。
接着就可以开始输入操作数据,每一条操作命令都会进入队列。
最后执行EXEC,在队列中的命令得到执行。
比如这样:
> MULTI
OK
> INCR foo
QUEUED
> INCR bar
QUEUED
> EXEC
1) (integer) 1
2) (integer) 1
如果事务中出现错误怎么办?
首先我们将事务中的错误分为两类:
- 进入队列前发现错误,比如命令的语法错误。
- EXEC执行后发现错误,比如对同一个key执行的两次不同数据类型的操作。
第一种很好理解,就像上面给出的例子中,成功进入队列后会立马返回"QUEUED"。
如果没能进入队列,则整个事务都会失效,提示"Transaction discarded because of previous errors."
关于EXEC执行后出现的错误,凡是成功进入队列的都会被执行,即便同一事物中有执行失败的命令,其余的命令都会得到执行。
这让那些用过关系型数据库的人们感到诧异, 为什么Redis不支持roll back?
对此官网的两点说法:
- Redis commands can fail only if called with a wrong syntax (and the problem is not detectable during the command queueing), or against keys holding the wrong data type: this means that in practical terms a failing command is the result of a programming errors, and a kind of error that is very likely to be detected during development, and not in production.
- Redis is internally simplified and faster because it does not need the ability to roll back.
有人说不支持roll back会引发各种bug。但需要明白的是,roll back不是用来解决编程层面上的错误的。
而且,导致命令失败只有两种可能:
- 语法错误
- 执行了与key的数据类型不匹配的操作
鉴于此,roll back几乎没有任何意义,Redis更倾向于不支持roll back而是保持简洁和高效。
丢弃事务
DISCARD可以用作丢弃当前事务,并将连接状态恢复为正常状态。
使用方法如下:
> SET foo 1
OK
> MULTI
OK
> INCR foo
QUEUED
> DISCARD
OK
> GET foo
"1"
原子性
check-and-set(CAS)之类的操作往往会出现竟态条件。
Redis提供了WATCH用于观察key的变化。
当一个被观察的key在EXEC执行前变化时,整个事务会终止并返回Nil,对该key的观察也会结束。
刚接触WATCH的时候,感觉这种处理方式很晦涩。不能加个显示锁什么的吗?
好在官网给出了充分的说明,先假设Redis没有提供INCR,我们现在要模拟一个递增操作:
val = GET mykey
val = val + 1
SET mykey $val
一个client进行该操作时是没有问题,但多个client一起进行该操作时会出现竟态条件。
比如A和B两个client同时进行了GET mykey,得到的都是10,因此两次执行的结果是11而不是12。
而加入WATCH后:
WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC
如果WATCH和EXEC之间有其他的什么东东改变了被观察的key,该事务则会失败。
如果希望本次事务执行成功则需要在循环中执行,当然,这也是一种locking方式。
事实上,多个client访问同一key的冲突并不常见,看具体情况进行操作吧。
相应地,也有UNWATCH可以用于释放所有被观察的key。
比如下面的例子中,事务内的INCR会成功执行:
WATCH key
UNWATCH key
MULTI
INCR key
EXEC