是什么
-
事务的状态:
-
官网:https://redis.io/docs/manual/transactions/
-
可以一次执行多个命令,本质是一组命令的集合,一个事务中的所有命令都会序列化,按顺序地串行化执行而不会被其他命令插入,不许加塞
能干嘛
- 一个队列中,一次性、顺序性、排他性的执行一系列命令
Redis 事务 VS 数据库事务
对比 | 详细解释 |
---|---|
单独的隔离操作 | Redis的事务仅仅是保证事务里的操作会被连续独占的执行,redis命令执行是单线程架构,在执行完事务内所有指令前是不可能再去同时执行其他客户端的请求的 |
没有隔离级别的概念 | 因为事务提交前任何指令都不会被实际执行,也就不存在”事务内的查询要看到事务里的更新,在事务外查询不能看到”这种问题了 |
不保证原子性 | Redis的事务不保证原子性(部分支持),也就是不保证所有指令同时成功或同时失败,只有决定是否开始执行全部指令的能力,没有执行到一半进行回滚的能力 |
排它性 | Redis会保证一个事务内的命令依次执行,而不会被其它命令插入 |
怎么玩
- 官网 :https://redis.io/docs/manual/transactions/
- 常用命令
-
case1:正常执行
MULTI
、EXEC
-
case2:放弃事务
MULTI
、DISCARD
-
case3:全体连坐,一个语法出错,全体连坐。如果任何一个命令语法有错,Redis 会直接返回错误,所有的命令都不会执行
-
case4:源头债主
-
case5:watch监控
- Redis使用 Watch 来提供乐观锁定,类似于 CAS(Check-and-Set)
- 悲观锁:悲观锁(Pessimistic Lock),顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。
- 乐观锁:乐观锁(Optimistic Lock),顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据。
- 乐观锁策略:提交版本必须【大于】记录当前版本才能执行更新。
- 与悲观锁不同,乐观锁不会在操作前加锁,而是在提交修改时检查数据是否被其他客户端修改过。如果数据未被修改,则提交成功;否则,操作失败,客户端可以选择重试或放弃。
- CAS
- watch
-
初始化 k1 和 balance 两个 key,先监控在开启 multi,保证两个 key 变动在同一个事务内
-
有加塞篡改:watch 命令是一种乐观锁的实现,Redis 在修改的时候会检测数据是否被更改,如果被更改了,则执行失败
-
- unwatch
- Redis使用 Watch 来提供乐观锁定,类似于 CAS(Check-and-Set)
-
小结:
- 一旦执行了 exec 之前加的监控锁都会被取消掉
- 当客户端连接丢失的时候(比如退出链接),所有东西都会被取消监视