Redis事务
1.Redis 的事务是什么
1、Redis 事务是一个单独的隔离操作:事务中的所有命令都会序列化、按顺序地执行
2、事务在执行的过程中,不会被其他客户端发送来的命令请求所打断
3、Redis 事务的主要作用就是串联多个命令防止别的命令插队
4、Redis事务具有隔离性但不具备原子性
2.Redis 事务三特性
2.1单独的隔离操作
1、事务中的所有命令都会序列化、按顺序地执行 2、事务在执行的过程中,不会被其他客户端发送来的命令请求所打断
2.2没有隔离级别的概念
队列中的命令(指令), 在没有提交前都不会实际被执行
2.3不保证原子性
事务执行过程中, 如果有指令执行失败,其它的指令仍然会被执行, 没有回滚
3.事务相关指令 Multi、Exec、discard
- Redis 事务指令示意图
- 解读上图
- 从输入 Multi 命令开始,输入的命令都会依次进入命令队列中,但不会执行(类似 Mysql 的 start transaction 开启事务)
- 输入 Exec 后,Redis 会将之前的命令队列中的命令依次执行(类似 Mysql 的 commit 提 交事务)
- 组队的过程中可以通过 discard 来放弃组队(类似 Mysql 的 rollback 回顾事务)
- Redis 事务和 Mysql 事务本质是完全不同的
- 注意事项和细节
1、组队的过程中, 可以通过 discard 来放弃组队
2、如果在组队阶段报错, 会导致 exec 失败, 那么事务的所有指令都不会被执行
3、如果组队成功, 但是指令有不能正常执行的, 那么 exec 提交, 会出现有成功有失败情况, 也就是事务得到部分执行, 这种情况下, Redis 事务不具备原子性
shell
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set k1 v
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> INCR k1
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) OK
3) (error) ERR value is not an integer or out of range
#这种情况错误并不会影响正常执行的指令的结果
127.0.0.1:6379> get k1
"v"
4.事务冲突及解决方案
4.1.先看一个问题
- 经典的抢票问题,假设总共有10张票
- 一个请求想购买 6
- 一个请求想购买 5
- 一个请求想购买 1
- 解读上图
- 如果没有控制, 会造成超卖现象
- 如果 3 个指令, 都得到执行, 最后剩余的票数是 -2
4.2悲观锁
- 工作示意图
- 解读上图
- 悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修 改,所以每次在拿数据的时候都会上锁
- 这样别人/其它请求想拿这个数据就会 block 直到它拿到锁。
- 悲观锁是锁设计理念, 传统的关系型数据库里边就用到了很多这种锁机制,比如行锁, 表锁等,读锁,写锁等,都是在做操作之前先上锁.
4.3乐观锁
- 工作示意图
- 解读上图
- 乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会 修改,所以不会上锁
- 但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等 机制。
- 乐观锁适用于多读的应用类型,这样可以提高吞吐量。Redis 就是利用这种 check-and-set 机制实现事务的
- 乐观锁是锁设计理念
4.4watch & unwatch
- watch
1、基本语法: watch key [key ...] 2、在执行 multi 之前,先执行 watch key1 [key2],可以监视一个(或多个) key ,如果在 事务执行之前这个(或这些) key 被其他命令所改动,那么事务将被打断.
3、这里可以结合乐观锁机制进行理解.
- unwatch
1、基本语法 unwatch 2、取消 watch 命令对所有 key 的监视。 3、如果在执行 watch 命令后,exec 命令或 discard 命令先被执行了的话,那么就不 需要再执行 unwatch 了