Redis事务是什么
可以一次执行多个命令,本质是一组命令的集合,一个事务中的所有命令都会序列化,按顺序串行,而不会被其他命令插入。
其作用就是在一个队列中,一次性、顺序、排他的执行一系列命令。
Redis事务 VS 数据库事务
– | – |
---|---|
单独的隔离操作 | Redis的事务仅仅是保证事务里的操作会被连续独占的执行,redis命令执行是单线程架构,在执行完事务内所有指令前是不可能再去同时执行其他客户端的请求的 |
没有隔离级别的概念 | 因为事务提交前任何指令都不会被实际执行,也就不存在”事务内的查询要看到事务里的更新,在事务外查询不能看到”这种问题了 |
不保证原子性 | Redis的事务不保证原子性,也就是不保证所有指令同时成功或同时失败,只有决定是否开始执行全部指令的能力,没有执行到一半进行回滚的能 |
排它性 | Redis会保证一个事务内的命令依次执行,而不会被其它命令插入 |
Redis事务命令
DISCARD | 取消事务,放弃执行事务块内的所有命令 |
EXEC | 执行所有事务块内的命令 |
MULTI | 标记一个事务块的开始 |
UNWATCH | 取消WATCH命令对所有key的监视 |
WATCH key [key…] | 监视一个key或多个key,如果在事务执行前,监视的key被其他命令所改动,那么事务将被打断 |
Redis事务举例
正常执行
放弃事务
全体连坐
冤头债主
Redis不提供事务回滚的功能,开发者必须在事务执行出错后,自行恢复数据库状态
WATCH监控
- 悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁
- 乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据。
乐观锁策略:提交版本必须 大于 记录当前版本才能执行更新 - Redis使用WATCH来提供乐观锁定,类似于CAS
案例
watch命令是一种乐观锁的实现,Redis在修改的时候会检测数据是否被更改,如果更改了,则执行失败
第一个窗口蓝色框第5步执行结果返回为空,也就是相当于是失败,笔记见最下面官网说明
UNWATCH
一旦执行了EXEC,则之前加的监控锁都会被取消了
当客户端连接丢失的时候,会取消所有监视。
总结
开启事务:MULTI,以此命令开始一个事务
入队:将多个命令入队到事务中,接收到的命令不会立即执行,而是放到等待执行的队列里
执行:EXEC,由此命令触发事务