目录
一, 什么是Redis事务
Redis的事务和MySQL的事务概念上是类似的,都是把一系列操作绑定成一组,让这组操作能够批量执行,但是Redis事务和MySQL事务又不完全一样,Redis事务的特点如下:
- 弱化的原⼦性: redis 没有 "回滚机制",只能做到这些操作 "批量执⾏",不能做到 "⼀个失败就恢复到 初始状态"(MySQL一旦某条命令执行失败就会回滚到最初的状态);
- 不保证一致性:不涉及"约束",也没有回滚机制,事务执行过程中如果修改操作出现失败,就可能引起不一致的情况;
- 不需要隔离性:Redis是一个单线程模型的服务器程序,所有的请求都是串行执行的,故没有隔离级别;
- 不需要持久性:Redis本身是一个内存数据库,数据是存储在内存中的,虽然Redis也有持久化机制,但是这里的持久化和事务没有什么直接关系(因为Redis的持久化也可以在配置文件中进行关闭).
MySQL事务的特性可以参考我的另一篇博客有详细讲解:
二, Redis事务相关操作
2.1 MULTI
开启一个事务,执行成功返回OK
127.0.0.1:6379> MULTI
OK
2.2 EXEC
真正执行事务
MULTI
OK
127.0.0.1:6379> set k1 1
QUEUED
127.0.0.1:6379> set k2 2
QUEUED
127.0.0.1:6379> set k3 3
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) OK
3) OK
每次添加一个操作,都会提示"QUEUED",说明命令已经进入客户端队列了(就是事务队列),每次执行EXEC的时候,客户端才会真正把上述操作发送给服务器.
2.3 DISCARD
放弃当前事务,此时直接清空事务队列,之前的操作都不会真正执⾏到
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 1
QUEUED
127.0.0.1:6379> set k2 2
QUEUED
127.0.0.1:6379> DISCARD
OK
127.0.0.1:6379> get k1
(nil)
127.0.0.1:6379> get k2
(nil)
2.4 WATCH
在执行事务时,如果某个事务中修改的值,别的客户端修改了,此时就容易出现数据不一致的问题
# 客⼾端1 先执⾏
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set key 100
QUEUED
# 客⼾端2 再执⾏
127.0.0.1:6379> set key 200
OK
# 客⼾端1 最后执⾏
127.0.0.1:6379> EXEC
1) OK
127.0.0.1:6379> get key
"100"
从时间上看,客户端是先发送了 set key 100,客户端是后发送了 set key 200,由于客户端2中是先执行了exec执行了,才会真正执行 set key 100,这个操作变成了实际上更晚执行的操作,最终值是100.
watch命令就是用来解决这个问题的,watch在该客户端上监控一组具体的key
- 当开启事务的时候,如果对watch的key进行修改,就会记录当前key的"版本号"(版本号是个简单的整数,每次修改都会使版本变大,服务器来维护每个key的版本号情况)
- 当真正提提交事务的时候,如果发现当前服务器上的key的版本号已经超过了事务开始时的版本号,就会让事务执行失败(事务中的所有操作都不执行)
# 客户端1 先执行
127.0.0.1:6379> watch k1 # 开始监控 k1
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 100 # 进⾏修改, 从服务器获取 k1 的版本号是 0. 记录 k1 的版本号
QUEUED
127.0.0.1:6379> set k2 1000
QUEUED
# 只是⼊队列, 但是不提交事务执⾏
# 客⼾端2 再执⾏
127.0.0.1:6379> set k1 200 # 修改成功, 使服务器端的 k1 的版本号 0 -> 1
OK
# 客⼾端1 再执⾏
127.0.0.1:6379> EXEC # 真正执⾏修改操作, 此时对⽐版本发现, 客⼾端的 k1 的版本
(nil)
127.0.0.1:6379> get k1
"200"
127.0.0.1:6379> get k2
(nil)
# 此时说明事务已经被取消了. 这次提交的所有命令都没有执⾏
2.5 UNWATCH
取消对key的监控,相当于WATCH的逆操作