1. 概述
事务提供了一种“将多个命令打包, 然后一次性、按顺序地执行”的机制。
redis> MULTI //开始一个事务
OK
redis> SET book-name "Mastering C++ in 21 days" // 事务中的指令返回的都是QUEUED
QUEUED
redis> GET book-name
QUEUED
redis> SET NAME 123
QUEUED
redis> EXEC //执行这个事务所QUEUED的所有指令,并返回所有指令结果
1) OK
2) "Mastering C++ in 21 days"
3) OK
当遇到exec指令时,会执行事务的所有指令,但如果某个指令失败,也不会停止,将会继续执行下面的命令。即可以保证原子性,但没有回滚的功能。
2. 机制
每个事务都有一个自己的事务指令队列。每个事务当遇到exec时,就会把队列中所有的指令拿出来执行。无论是否成功。
3. 特性
事务在执行的期间不会主动中断 —— 服务器在执行完事务中的所有命令之后, 才会继续处理其他客户端的其他命令。
这是官网上的一句话,但注意理解下含义。
- 一个事务开始后分为两个阶段:发送指令阶段---exec执行阶段。
- 上面说的事务执行期间不会被中段,不会处理其他客户端指令--这里是指exec执行阶段,并不是说发送指令阶段。
- 发送指令阶段,完全是可以处理其他客户端的指令的。
4. watch
watch
命令用于在事务开始之前监视任意数量的键: 当调用 [EXEC]命令执行事务时, 如果任意一个被监视的键已经被其他客户端修改了, 那么整个事务不再执行, 直接返回失败。
在T5时,就会失败。即这个事务被废弃掉,这个事务的其他命令就不会再执行。
watch
指令只在事务开始之前执行。但事务中间执行watch
指令
5. discard
这个指令很简单了,就是放弃这个事务,结束这个事务,这个事务的指令不会被执行。
redis> SET foo 1
OK
redis> MULTI
OK
redis> INCR foo
QUEUED
redis> DISCARD
OK
redis> GET foo
"1"
6. 使用watch实现CAS
我们知道CAS一般都是硬件级别提供的原子性保证,那我们也可以使用redis的watch来实现CAS的效果:
bool CAS(mykey, originValue, destValue){
WATCH mykey
val = GET mykey
if (val == originValue) {
MULTI
SET mykey $val //就是set指令执行时,如果mykey发生改变就放弃,CAS返回失败
v = EXEC
if (v != null){ //如果set成功,则就说明CAS成功
return true
} else {
return false
}
}
}
7. ACID
Redis事务是满足了ACI特性,不满足D。
A:原子性。要么全部执行,要么全部不执行。满足的,注意:A和回滚功能是两个概念。
C:一致性。如果出现数据错误,在exec就可以发现,导致执行失败,可以满足数据的一致性
I:隔离性。因为在exec阶段,redis是单线程执行,保证了事务的序列化执行,自然保证了隔离性。