第五章_Redis事务

是什么

官网 

第五章_Redis事务_第1张图片

能做什么

一个队列中,一次性、顺序性、排他性的执行一系列命令

Redis事务 VS 数据库事务

1 单独的隔离操作
Redis的事务仅仅是保证事务里的操作会被连续独占的执行,redis命令执行是单线程架构,在执行完事务内所有指令前是不可能再去同时执行其他客户端的请求的
2 没有隔离级别的概念
因为事务提交前任何指令都不会被实际执行,也就不存在”事务内的查询要看到事务里的更新,在事务外查询不能看到”这种问题了
3不保证原子性
Redis的事务 不保证原子性,也就是不保证所有指令同时成功或同时失败,只有决定是否开始执行全部指令的能力,没有执行到一半进行回滚的能力
4 排它性
Redis会保证一个事务内的命令依次执行,而不会被其它命令插入

怎么使用

常用命令

第五章_Redis事务_第2张图片

case1:正常执行

MULTI

EXEC

第五章_Redis事务_第3张图片

Case2:放弃事务

MULTI

DISCARD

案例演示:

第五章_Redis事务_第4张图片

官网说明:

第五章_Redis事务_第5张图片

Case3:全体连坐 

第五章_Redis事务_第6张图片

官网说明

第五章_Redis事务_第7张图片

Case4:冤头债主 

第五章_Redis事务_第8张图片

官网说明

第五章_Redis事务_第9张图片

补充

Redis不提供事务回滚的功能,开发者必须在事务执行出错后,自行恢复数据库状态

第五章_Redis事务_第10张图片

注意和传统数据库事务区别,不一定要么一起成功要么一起失败

Case5:watch监控

Redis使用Watch来提供乐观锁定,类似于CAS(Check-and-Set)

悲观锁

悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。

乐观锁

乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据。

乐观锁策略:提交版本必须   大于   记录当前版本才能执行更新

CAS

第五章_Redis事务_第11张图片

watch

初始化k1和balance两个key,先监控再开启multi,保证两key变动在同一个事务内 

第五章_Redis事务_第12张图片

有加塞篡改

watch命令是一种乐观锁的实现,Redis在修改的时候会检测数据是否被更改,如果更改了,则执行失败

第一个窗口蓝色框第5步执行结果返回为空,也就是相当于是失败,笔记见最下面官网说明

第五章_Redis事务_第13张图片

第五章_Redis事务_第14张图片

unwatch 

第五章_Redis事务_第15张图片

小结

一旦执行了exec之前加的监控锁都会被取消掉了

当客户端连接丢失的时候(比如退出链接),所有东西都会被取消监视

小总结 

开启:以MULTI开始一个事务

入队:将多个命令入队到事务中,接到这些命令并不会立即执行,而是放到等待执行的事务队列里面

执行:由EXEC命令触发事务

你可能感兴趣的:(#,redis,redis,数据库,java)