【Redis学习笔记】第七章 Redis事务

---

---

1、事务

redis事务就是一个命令执行的队列，将一系列预定义命令包装成一个整体（一个队列）。当执行时，一次性按照添加顺序依次执行，中间不会被打断或者干扰。

简单说就是：

一个队列中，一次性、顺序性、排他性的执行一系列命令

形象说就是：

干一件事情的时候，被其他事情打断，可能会导致正在干的事情出现错误或者纰漏。

2、事务的基本操作

• 开启事务

指令：
multi

作用：
设定事务的开启位置，执行这条指令后，后续的所有指令均加入到事务中
1
2
3
4
5

• 执行事务

指令：
exec

作用：
设定事务结束的位置，同时执行事务，与multi成对使用
1
2
3
4
5

注：
加入事务的命令暂时进入到任务队列中，并没有立即执行，只有执行exec命令才开始执行

• 取消事务

指令：
discard

作用：
定义事务的过程中发现错误了，可终止当前事务的定义。发生在multi之后，exec之前
1
2
3
4
5

实例：

127.0.0.1:6379 > multi
OK

127.0.0.1:6379 > set name 9527
QUEUED
127.0.0.1:6379 > get name
QUEUED
127.0.0.1:6379 > set name llg
QUEUED
127.0.0.1:6379 > get name
QUEUED

127.0.0.1:6379 > exec
1) OK
2) "9527"
3) OK
4) "llg"

//中止
127.0.0.1:6379 > multi
OK
127.0.0.1:6379 > set age 22
QUEUED
127.0.0.1:6379 > discard
OK
127.0.0.1:6379 > exec
(error)ERR EXEC without MULTI //这时再执行exec就报错了
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

事务的工作流程如下图：

注意事项：

• 定义事务的过程中，有一个命令存在语法错误，整体事务中所有命令均不会执行，包括那些语法正确的命令
  

• 定义事务的过程中，无语法错误，但逻辑错误导致不能正确执行，如对string进行lpush。这时能正确运行的指令会被执行，运行错误的命令不会被执行。
  

3、基于特定条件的事务执行–锁

引入场景：

双11热卖过程中，对已经售罄的货物追加补货，多个业务员都有权限进行补货，如何保证这个操作不会被重复进行？

解决方案：

指令：
watch key1 [key2] …

作用：
对key添加监视锁，在执行exec前如果key发生了变化，终止事务执行
1
2
3
4
5

指令：
unwatch

作用：
取消对所有key的监视
1
2
3
4
5

举例：

注：

• multi后不能出现watch
  

• watch之后，multi之前的时间，进行其他操作没问题
  
  
  

4、分布式锁

引入场景：

补完货以后，3秒内将所有商品被抢购完毕，如何避免最后一件商品不被多人同时购买？【超卖问题】

解决方案：

指令：（类比上厕所锁门）
setnx lock-key value //value随便写：666、ture……

作用：
使用setnx设置一个公共锁，根据setnx返回值的特征，有值则设置失败，无值则设置成功。
设置成功时，你拥有控制权，可进行下一步业务操作
设置失败时，不具有控制权，排队或等待
1
2
3
4
5
6
7

指令：（类比上完厕所开门）
del lock-key

作用：
del后，其余客户再setnx锁，就可以成功了
1
2
3
4
5

就像公厕的锁，有人你就上不了，没人你就可以上厕所。

举例：

5、死锁

引入场景：

依赖分布式锁的机制，某个用户操作时对应客户端宕机，且此时已经获取到锁。如何解决？

业务分析:

锁是用户加的，必定存在加锁后未解锁的风险，所以解锁不能仅仅依赖客户控制，要给出系统级别的保底处理方案。

解决方案：

指令：
expire lock-key second
pexpire lock-key milliseconds

作用：
为锁key添加时间限定，到时不释放，放弃锁
1
2
3
4
5
6

实例：