微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

Redis事务操作

Redis事务操作

Redis事务本质:

一组命令的集合 , 一个事务中的所有命令都会被序列化 , 在事务执行过程中 , 会按照顺序执行

  • 一次性 : 事务之间的事情,会一次性执行,而不是立刻执行
  • 顺序性 : 会按照顺序进行执行
  • 排他性 : 事务过程中,不允许被其他事情影响

Redis事务没有隔离级别的概念

Redis单条命令保存原子性 , 但事务不保证原子性

redis事务 :

  • 开启事务( multi )
  • 命令入队( 写命令 )
  • 执行事务( exec )

所以事务中的命令在加入时都没有被执行,直到提交时才会开始执行( Exec )一次性完成

事务

正常流程

127.0.0.1:6379> multi         # 开启事务
OK
127.0.0.1:6379> set k1 v1     # 存入 k1:v1
QUEUED
127.0.0.1:6379> set k2 v2     # 存入 k2:v2
QUEUED
127.0.0.1:6379> get k1        # 获取k1对应的值
QUEUED
127.0.0.1:6379> set k3 v3     # 存入 k3:v3
QUEUED
127.0.0.1:6379> keys *        # 查看全部的key
QUEUED
127.0.0.1:6379> exec          # 执行上面命令,下面是依次的结果
1) OK
2) OK
3) "v1"
4) OK
5) 1) "k3"
   2) "k2"
   3) "k1"
   4) "sign"

1

取消事务 (discard)

如果你在执行之前取消事务,那么你之前的操作都会取消,存入的元素也会当作没存

127.0.0.1:6379> multi             # 开启事务
OK
127.0.0.1:6379> set k1 v1         # 存入 k1:v1
QUEUED
127.0.0.1:6379> discard           # 取消事务
OK
127.0.0.1:6379> exec              # 执行事务,因为已经取消事务,会报错
(error) ERR EXEC without MULTI    
127.0.0.1:6379> get k1            # 获取k1的值,但是取消事务了,k1为null
(nil)

3

错误示例

1.一次只能添加一个

127.0.0.1:6379> multi             # 开启事务
OK
127.0.0.1:6379> set k1 v1 k2 v2   # 存入 k1:v1、k2:v2
QUEUED
127.0.0.1:6379> keys *            # 查看全部的key
QUEUED
127.0.0.1:6379> exec              # 执行上面命令
1) (error) ERR Syntax error
2) (empty array)

2

2.代码语法错误

代码语法错误 ( 编译时异常 ) , 所有的命令都不执行

127.0.0.1:6379> multi        # 开启事务
OK
127.0.0.1:6379> set k v      # 存入 k:v
QUEUED
127.0.0.1:6379> error k      # 输入了一个错误语句,报错,而且看似没影响后面的语句
(error) ERR unkNown command `error`, with args beginning with: `k`, 
127.0.0.1:6379> get k        # 获取k的值
QUEUED
127.0.0.1:6379> exec         # 执行事务
(error) EXECABORT Transaction discarded because of prevIoUs errors.
127.0.0.1:6379> get k        # 事务已经结束,之后获取k的值
(nil)

4

3.代码逻辑错误

代码逻辑错误 ( 运行时异常 ) , 其他命令可以正常执行

所以不保证事务原子性

127.0.0.1:6379> multi       # 开启事务
OK
127.0.0.1:6379> set k v     # 存入 k:v
QUEUED
127.0.0.1:6379> incr k      # 元素k的值+1
QUEUED
127.0.0.1:6379> get k       # 获取k的值
QUEUED
127.0.0.1:6379> exec        # 执行事务
1) OK
2) (error) ERR value is not an integer or out of range
3) "v"

5

监控watch

1.乐观锁、悲观锁

悲观锁:

  • 很悲观 , 认为什么时候都会出现问题 , 所以无论做什么都会加锁

乐观锁:

  • 很乐观 , 认为什么时候都不会出现问题 , 所以不会上锁

可以采用的解决方法

  • 更新数据的时候去判断一下 , 在此期间是否有人修改过这个数据
  • 获取version
  • 更新的时候比较version

在Redis中可以采用:

使用watch key监控指定数据 , 相当于乐观锁加锁

2.正常执行

以下用操纵100元的例子进行模拟:

127.0.0.1:6379> set money 100    # 存入money100
OK
127.0.0.1:6379> set out 0        # 此时支出为0
OK
127.0.0.1:6379> watch money      # 对money进行监控
OK
127.0.0.1:6379> multi            # 开启事务
OK
127.0.0.1:6379> decrby money 10  # 使用了10元钱
QUEUED
127.0.0.1:6379> incrby out 10    # 支出的钱增加10元
QUEUED
127.0.0.1:6379> exec             # 执行事务
1) (integer) 90
2) (integer) 10

测试多线程修改值 , 使用watch可以当做redis的乐观锁操作:

线程1:

127.0.0.1:6379> watch money         # 对money进行监控
OK
127.0.0.1:6379> multi               # 开启事务
OK
127.0.0.1:6379> decrby money 20     # 使用money20
QUEUED
127.0.0.1:6379> incrby out 20       # 支出增加20
QUEUED
127.0.0.1:6379>                      

在线程1没执行事务的时候,线程2对money进行操作:

127.0.0.1:6379> incrby money 300    # 此时线程1还没执行,增加money300
(integer) 390

此时,线程1执行事务:

127.0.0.1:6379> exec                # 线程1执行,但是另一个线程修改了我们的值,这个时候就会导致事务执行失败
(nil)
127.0.0.1:6379> get money           # 因为事务执行失败,所以只是线程2的money修改结果
"390"
127.0.0.1:6379> get out             # 因为事务执行失败,支出数值没有被修改
"10"

个人博客为:
MoYu's HomePage

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐