llp-blog

Appearance

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 事务指令示意图

image-20230125094106044

  • 解读上图
  1. 从输入 Multi 命令开始，输入的命令都会依次进入命令队列中，但不会执行(类似 Mysql 的 start transaction 开启事务)
  2. 输入 Exec 后，Redis 会将之前的命令队列中的命令依次执行(类似 Mysql 的 commit 提 交事务)
  3. 组队的过程中可以通过 discard 来放弃组队(类似 Mysql 的 rollback 回顾事务)
  4. Redis 事务和 Mysql 事务本质是完全不同的

image-20230125100040739

  • 注意事项和细节

1、组队的过程中, 可以通过 discard 来放弃组队

image-20230125100234309

2、如果在组队阶段报错, 会导致 exec 失败, 那么事务的所有指令都不会被执行

image-20230125100722004

image-20230125100630388

3、如果组队成功, 但是指令有不能正常执行的, 那么 exec 提交, 会出现有成功有失败情况, 也就是事务得到部分执行, 这种情况下, Redis 事务不具备原子性

image-20230125100715896

image-20230125100731072

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"
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张票
  1. 一个请求想购买 6
  2. 一个请求想购买 5
  3. 一个请求想购买 1

image-20230125101337475

  • 解读上图
  1. 如果没有控制, 会造成超卖现象
  2. 如果 3 个指令, 都得到执行, 最后剩余的票数是 -2

4.2悲观锁 ​

  • 工作示意图

image-20230125101832683

  • 解读上图
  1. 悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修 改，所以每次在拿数据的时候都会上锁
  2. 这样别人/其它请求想拿这个数据就会 block 直到它拿到锁。
  3. 悲观锁是锁设计理念, 传统的关系型数据库里边就用到了很多这种锁机制，比如行锁， 表锁等，读锁，写锁等，都是在做操作之前先上锁.

4.3乐观锁 ​

  • 工作示意图

image-20230125104219833

  • 解读上图
  1. 乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会 修改，所以不会上锁
  2. 但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等 机制。
  3. 乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis 就是利用这种 check-and-set 机制实现事务的
  4. 乐观锁是锁设计理念

4.4watch & unwatch ​

  • watch

1、基本语法: watch key [key ...] 2、在执行 multi 之前，先执行 watch key1 [key2],可以监视一个(或多个) key ，如果在 事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断.

3、这里可以结合乐观锁机制进行理解.

image-20230125103440668

  • unwatch

1、基本语法 unwatch 2、取消 watch 命令对所有 key 的监视。 3、如果在执行 watch 命令后，exec 命令或 discard 命令先被执行了的话，那么就不 需要再执行 unwatch 了