一、是什么
- 可以一次执行多个命令,本质是一组命令的集合。
- 一个事务中的所有命令都会序列化,按照顺序地串行化执行而不会被其他命令插入,不许加塞
二、能干嘛
- 一个队列中,一次性、顺序性、排他性的执行一系列命令
三、怎么玩
- Redis中开启事务的命令是:MULTI ,这个命令通常会回复一个OK【回复的是OK,但是这个事能不能办,什么时候办,办不办的成不知道】,用户将会一次性的打多个命令,而代替执行,按顺序执行,Redis将这些命令入队,所有的命令将会通过命令:EXEC 来被调用执行。
- 如果用命令:DISCARD 表示放弃丢弃,言下之意是放弃本次的批处理操作
常用命令:
- DISCARD:取消事务,放弃执行事务块内的所有命令
- EXEC:执行所有事务块内的命令
- MULTI:标记一个事务块的开始
- UNWATCH:取消 WATCH 命令对所有 key 的监控
- WATCH key [key . . . ]:件事一个(或多个)key,如果在事务执行之前这个(或这些)key被其他命令所改动,那么事务将被打断
正常执行:
放弃事务:
全体连坐:【在事务块中只要有一条命令执行是错的,那么整个事务块就不会执行】
冤头债主:【如果在事务块中所有命令都正确,但是结果会产生错误,那么冤有头债有主,谁错找谁】
watch监控:
- 悲观锁
- 悲观锁(Pessimistic Lock),顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,当其他线程想要访问数据时,都需要阻塞挂起。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁、表锁,读锁,写锁等,都是在操作之前先上锁。
- 在Java中,synchronized的思想也是悲观锁。
- 乐观锁:【冲突检测和数据更新】
- 乐观锁(Optimistic Lock),顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候回判断一下再次期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量。
- 乐观锁策略:提交版本必须大于记录当前版本才能执行更新
- 一般会使用版本号机制或CAS操作实现:
- version方式:一般是在数据表中加上一个数据版本号version字段,表示数据被修改的次数,当数据被修改时,version值会加一。当线程A要更新数据值时,在读取数据的同时也会读取version值,在提交更新时,若刚才读取到的version值为当前数据库中的version值相等时才更新,否则重试更新操作,直到更新成功。
核心SQL代码:
update table set x=x+1, version=version+1 where id=#{id} and version=#{version};
- CAS(Check And Set【先检查再动手设置】)
- CAS操作方式:即 compare and set,CAS是乐观锁技术,涉及到三个操作数,数据所在的内存值,预期值,新值。当需要更新时,判断当前内存值与之前取到的值是否相等,若相等,则用新值更新,若失败则重试,一般情况下是一个自旋操作,即不断的重试。
********************************************************************
*无加塞篡改,先监控再开启 MULTI ,保证两笔金额变动在同一个事务内*
********************************************************************
- 如下图:就模拟了一个购物的过程,在买的过程中,别人会给你打钱,当你要完成支付的时候报错了
- 解决:【使用 UNWATCH 取消对当前 key 的监控,之后再一次进行监控(得到最新的数据),直到成功为止】
注意:
**********************************************
一旦执行了 EXEC,之前加的监控所都会被取消掉*
**********************************************
四、小结
- 通过 WATCH 命令在事务执行之前监控了多个 Keys,倘若在 WATCH 之后有任何 Key 的值发生变化,EXEC 命令执行的事务都将被放弃,同时返回 Nullmulti-bulk 应答以通知调用者事务执行失败
五、三阶段
- 开启:以 MULTI 开始一个事务
- 入队:将多个命令入队到事务中,接到这些命令并不会立即执行,而是放到等待执行的事务队列里面
- 执行:由 EXEC 命令触发事务
六、三特性
- 单独的隔离操作:事务中所有的命令多会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断
- 没有隔离级别的概念:队列中的命令没有提交之前都不会实际的被执行,因为事务提交前任何指令都不会被实际的执行,也就是不存在 “ 事务内的查询要看到事务里面的更新,在事务外查询不能看到 ” 这个是让人万分头痛的问题
- 不保证原子性:Redis 同一个事务中如果有一条命令执行失败,其后的命令仍然会被执行,没有回滚