1、事务
redis事务就是一个命令执行的队列，将一系列预定义命令包装成一个整体（一个队列）。当执行时，一次性按照添加顺序依次执行，中间不会被打断或者干扰。
简单说就是：
一个队列中，一次性、顺序性、排他性的执行一系列命令
形象说就是：
干一件事情的时候，被其他事情打断，可能会导致正在干的事情出现错误或者纰漏。
2、事务的基本操作
- 开启事务
指令：
multi
作用：
设定事务的开启位置，执行这条指令后，后续的所有指令均加入到事务中
- 执行事务
指令：
exec
作用：
设定事务结束的位置，同时执行事务，与multi成对使用
注：
加入事务的命令暂时进入到任务队列中，并没有立即执行，只有执行exec命令才开始执行
- 取消事务
指令：
discard
作用：
定义事务的过程中发现错误了，可终止当前事务的定义。发生在multi之后，exec之前
实例：
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就报错了
事务的工作流程如下图：
注意事项：
-
定义事务的过程中，有一个命令存在语法错误，整体事务中所有命令均不会执行，包括那些语法正确的命令
-
定义事务的过程中，无语法错误，但逻辑错误导致不能正确执行，如对string进行lpush。这时能正确运行的指令会被执行，运行错误的命令不会被执行。
3、基于特定条件的事务执行–锁
引入场景：
双11热卖过程中，对已经售罄的货物追加补货，多个业务员都有权限进行补货，如何保证这个操作不会被重复进行？
解决方案：
指令：
watch key1 [key2] …
作用：
对key添加监视锁，在执行exec前如果key发生了变化，终止事务执行
指令：
unwatch
作用：
取消对所有key的监视
举例：
注：
-
multi后不能出现watch
-
watch之后，multi之前的时间，进行其他操作没问题
4、分布式锁
引入场景：
补完货以后，3秒内将所有商品被抢购完毕，如何避免最后一件商品不被多人同时购买？【超卖问题】
解决方案：
指令：（类比上厕所锁门）
setnx lock-key value //value随便写：666、ture……
作用：
使用setnx设置一个公共锁，根据setnx返回值的特征，有值则设置失败，无值则设置成功。
设置成功时，你拥有控制权，可进行下一步业务操作
设置失败时，不具有控制权，排队或等待
指令：（类比上完厕所开门）
del lock-key
作用：
del后，其余客户再setnx锁，就可以成功了
就像公厕的锁，有人你就上不了，没人你就可以上厕所。
举例：
5、死锁
引入场景：
依赖分布式锁的机制，某个用户操作时对应客户端宕机，且此时已经获取到锁。如何解决？
业务分析:
锁是用户加的，必定存在加锁后未解锁的风险，所以解锁不能仅仅依赖客户控制，要给出系统级别的保底处理方案。
解决方案：
指令：
expire lock-key second
pexpire lock-key milliseconds
作用：
为锁key添加时间限定，到时不释放，放弃锁
实例：
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/146165.html
