Redis事务就是一组命令的集合!一个事务中的所有命令都会被序列化,在事务执行过程中,会按照顺序进行执行,具有一次性、顺序性、排他性
------ 队列 set set set 执行 ------
Redis事务没有隔离级别的概念!所有的命令在事务中,并没有直接被执行!只有发起执行命令的时候才会执行!Exec
Redis单条命令保证原子性,但是事务不保证原子性!就是如果进入队列的时候没有报错,在执行的时候如果前面的命令报错了不会影响后面的命令执行
Redis事务三个阶段:
-
开启事务( multi ) -
命令入列( …… ) -
执行事务( exec )
正常执行事务!
127.0.0.1:6379> multi #开启事务
OK
#命令入列
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> set k3 v3
QUEUED
127.0.0.1:6379(TX)> get k2
QUEUED
#执行事务
127.0.0.1:6379(TX)> exec
1) OK
2) OK
3) OK
4) "v2"
放弃事务
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> set k4 v4
QUEUED
127.0.0.1:6379(TX)> discard #取消事务
OK
127.0.0.1:6379> get k4 #事务队列中的所有命令都不会被执行
(nil)
编译型异常(代码有问题!命令有错!),事务中的所有命令都不会被执行!
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> set k3 v3
QUEUED
127.0.0.1:6379(TX)> getset k3 #错误的命令
(error) ERR wrong number of arguments for 'getset' command
127.0.0.1:6379(TX)> set k4 v4
QUEUED
127.0.0.1:6379(TX)> exec #执行事务报错
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get k3 #所有的命令都不会被执行!
(nil)
运行时异常( 1/0 ),如果事务队列中存在语法性错误,那么执行命令的时候,其他命令是可以继续执行,错误的命令进行报错显示
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> incr k1 #错误的命令,执行的时候会报错
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> set k3 v3
QUEUED
127.0.0.1:6379(TX)> get k3
QUEUED
127.0.0.1:6379(TX)> exec #第一条命令出错不影响后面的命令运行
1) (error) ERR value is not an integer or out of range
2) OK
3) OK
4) "v3"
127.0.0.1:6379> get k2
"v2"
127.0.0.1:6379> get k3
"v3"
监控!Watch( 面试常问 )
悲观锁:
-
很悲观,认为什么时候都会出问题,无论做什么都会加锁
乐观锁:
-
很乐观,认为上面时候都不会出问题,所以不会上锁!更新数据的时候去判断一下,在此期间是否有人修改过这个数据 -
获取version -
更新的时候比较version
Redis监视测试
正常执行成功!
127.0.0.1:6379> set money 100
OK
127.0.0.1:6379> set out 0
OK
127.0.0.1:6379> watch money
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> decrby money 20
QUEUED
127.0.0.1:6379(TX)> incrby out 20
QUEUED
127.0.0.1:6379(TX)> exec
1) (integer) 80
2) (integer) 20
127.0.0.1:6379>
测试多线程修改值,使用watch可以当作redis的乐观锁操作!
127.0.0.1:6379> watch money #监视money
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> decrby money 10 #将money的值增加10
QUEUED
127.0.0.1:6379(TX)> incrby out 10 #将money的值减少10
QUEUED
127.0.0.1:6379(TX)> exec #如果在此期间money的值被修改过的话,不会执行事务中的任何命令,同时事务回滚,无论是否会滚,Redis都会取消执行事务前的WATCH命令
(nil)
-
另外个客户端对money的值进行了修改
127.0.0.1:6379> set money 200
OK
127.0.0.1:6379> get money
"200"
如果修改失败了,获取最新的值就好,先unwatch取消监视,在重新对money进行监视
127.0.0.1:6379> unwatch #如果发现事务执行失败,就先解锁
OK
127.0.0.1:6379> watch money #获取最新的值,再次监视
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> decrby money 1
QUEUED
127.0.0.1:6379(TX)> incrby money 1
QUEUED
127.0.0.1:6379(TX)> exec #比对监视的值是否发生了变化
1) (integer) 199
2) (integer) 200
为什么Redis事务不支持回滚
-
Redis事务执行失败是因为错误的命令而失败,这是由于我们在输入命令的时候可能不小心输错了,所以这些错误的命令应该出现在开发的过程中被发现,可以减少事务的失败 -
因为Redis的简单事务,不支持回滚操作,所以保证了Redis的性能
原文始发于微信公众号(爱吃薯片):Redis事务
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/25992.html