Redis事务

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

(0)
小半的头像小半

相关推荐

发表回复

登录后才能评论
极客之音——专业性很强的中文编程技术网站,欢迎收藏到浏览器,订阅我们!