3.redis事务概念
redis事务与监控
author:simplewu
在redis中它的事务与批处理非常相似
redis中的事务(transaction)是一组命令的集合。事务同命令一样都是redis的最小执行单位,一个事务中的命令要么都执行,要么都不执行。事务的应用非常普遍,如银行转账过程中a给b汇款,首先系统从a的账户中将钱划走,然后向b的账户增加相应的金额。这两个步骤必须属于同一个事务,要么全执行,要么全不执行。否则只执行第一步,钱就凭空消失了,这显然让人无法接受。
redis 事务可以一次执行多个命令, 并且带有以下两个重要的保证:
- 事务是一个单独的隔离操作,事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。
- 事务是一个原子操作:事务中的命令要么全部被执行,要么全部都不执行
事务的三个步骤
- 开启事务:以multi开启一个事务。
- 命令入队:将多个命令添加到命令队列中,接到这些命令不会立即执行,而是放到等待执行的事务队列中。
- 执行事务:有exec执行事务。(或者discard取消执行)
multi | 标记一个事务块的开始。 |
---|---|
exec | 执行所有事务块内的命令。 |
discard | 取消事务,放弃执行事务块内的所有命令。 |
unwatch | 取消 watch 命令对所有 key 的监视。 |
watch key [key ...] | 监视一个(或多个) key ,如果在事务执行之前这个(或这些) key 被其他命令所改动,那么事务将被打断 |
常见案例:
正常执行:指的是队列的中所有操作全部都会执行
全部取消:指的是队列中的所有操作全部都会被取消
执行:discard
全体连坐:如果指令集中有一条在加入队列时报错,则队列中的所有指令全部取消。指的是有语法错误
冤有头债有主:如果指令已经加入到队列中,但执行失败,只有当前指令失败,其它继续执行。指的是已经添加到队列但是执行失败
watch监控
watch监控表示对需要操作的key添加一个乐观锁,防止另一个用户进行修改,导致结果错误。
悲观锁:
顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会被block直到它拿到锁。传统的关系型数据库里面就用到了很多这种锁,比如行锁,表锁,读锁,写锁等,都是在操作之前先上锁。
乐观锁:
顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。提交的版本号必须大于当前版本号才可以提交。
案例:
图一
图二
图解:当图一开启监控key “money”,开启事务的时候加入拿着的是版本1,在事务执行过程中图二第二个客户端修改了版本一的指,现在库中存在的是版本二,而incrby money 200 在执行exec的时候我们的是版本二,乐观锁在这个时候并不允许我们提交,因为当前库中版本是2而我们提交的版本也是2。提交的版本号必须大于当前版本号才可以提交。!!!!!!!!!!
通过watch命令在事务执行之前监控了多个keys,倘若在watch之后有任何的key的值发生了变化,exec命令执行的事务会被取消。
事务的三个特性
单独的隔离性:事务中的所有的命令都会序列化,按顺序执行,事务在执行过程中,不会被其它客户端发送过来的命令请求所打断。
没有隔离级别的概念:队列中的命令没有提交之前都不会实际的被执行,因为事务提交前任何指令都不会被实际执行,也就不存在”事务内的查询要看到事务里的更新。
不保证原子性:redis同一个事务中如果有一条命令执行失败,其后的命令仍然会被执行,没有回滚