码迷,mamicode.com
首页 > 其他好文 > 详细

Redis的事务

时间:2020-03-27 21:21:38      阅读:33      评论:0      收藏:0      [点我收藏+]

标签:账户   自己   card   set   mil   png   不同   exec   nts   

 redis中的事务定义

Redis中的事务(transaction)是一组命令的集合。

事务同命令一样都是Redis的最小执行单位,一个事务中的命令要么都执行,要么都不执行。
事务的原理是先将属于一个事务的命令发送给Redis,然后再让Redis依次执行这些命令。

Redis保证一个事务中的所有命令要么都执行,要么都不执行。如果在发送EXEC命令前客户端断线了,则Redis会清空事务队列,事务中的所有命令都不会执行。而一旦客户端发送了EXEC命令,所有的命令就都会被执行,即使此后客户端断线也没关系,因为Redis中已经记录了所有要执行的命令。

除此之外,Redis的事务还能保证一个事务内的命令依次执行而不被其他命令插入。试想客户端A需要执行几条命令,同时客户端B发送了一条命令,如果不使用事务,则客户端B的命令可能会插入到客户端A的几条命令中执行。如果不希望发生这种情况,也可以使用事务。

事务的应用

事务的应用非常普遍,如银行转账过程中A给B汇款,首先系统从A的账户中将钱划走,然后向B的账户增加相应的金额。这两个步骤必须属于同一个事务,要么全执行,要么全不执行。否则只执行第一步,钱就凭空消失了,这显然让人无法接受。

和传统的事务不同

和传统的mysql事务不同的事,即使我们的加钱操作失败,我们也无法在这一组命令中让整个状态回滚到操作之前

事务的基本操作
? 开启事务

multi

设定事务的开启位置,此指令执行后,后续的所有指令均加入到事务中
? 执行事务

exec

设定事务的结束位置,同时执行事务。与multi成对出现,成对使用

 演示2个客户端同时操作一个key,就会发现有问题

127.0.0.1:6379> set name test1
OK
127.0.0.1:6379> get name
"test2"
127.0.0.1:6379>
127.0.0.1:6379> set name test2
OK
127.0.0.1:6379>

 演示开启事务

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET AGE 30
QUEUED
127.0.0.1:6379> get age
QUEUED
127.0.0.1:6379> set age 31
QUEUED
127.0.0.1:6379> get age
QUEUED
127.0.0.1:6379> exec
1) OK
2) (nil)
3) OK
4) "31"

 演示在开启事务的过程中,发现操作事务。

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set age 32
QUEUED
127.0.0.1:6379> get age
QUEUED
127.0.0.1:6379> set age 33
QUEUED
127.0.0.1:6379> DISCARD
OK
127.0.0.1:6379> get age
"31"
127.0.0.1:6379>

 事务的执行流程

技术图片

 定义事务的过程中,命令格式输入错误怎么办?
语法错误
指命令书写格式有误

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set name test
QUEUED
127.0.0.1:6379> get name
QUEUED
127.0.0.1:6379> stde name
(error) ERR unknown command `stde`, with args beginning with: `name`,
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379>

处理结果
如果定义的事务中所包含的命令存在语法错误,整体事务中所有命令均不会执行。包括那些语法正确的命令。 

定义事务的过程中,命令执行出现错误怎么办?
运行错误
指命令格式正确,但是无法正确的执行。例如对list进行incr操作

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set name n1
QUEUED
127.0.0.1:6379> get name
QUEUED
127.0.0.1:6379> set name n2
QUEUED
127.0.0.1:6379> get name
QUEUED
127.0.0.1:6379> LPUSH name a b c
QUEUED
127.0.0.1:6379> get name
QUEUED
127.0.0.1:6379> exec
1) OK
2) "n1"
3) OK
4) "n2"
5) (error) WRONGTYPE Operation against a key holding the wrong kind of value
6) "n2"
127.0.0.1:6379> get name
"n2"
127.0.0.1:6379>

能够正确运行的命令会执行,运行错误的命令不会被执行 ,那就需要自己回滚一些脏数据了。

 注意:已经执行完毕的命令对应的数据不会自动回滚,需要程序员自己在代码中实现回滚。

手动进行事务回滚
? 记录操作过程中被影响的数据之前的状态
? 单数据: string
? 多数据: hash、 list、 set、 zset
? 设置指令恢复所有的被修改的项
? 单数据:直接set(注意周边属性,例如时效)
? 多数据:修改对应值或整体克隆复制

基于特定条件的事务执行——锁

业务场景

天猫双11热卖过程中,对已经售罄的货物追加补货, 4个业务员都有权限进行补货。补货的操作可能是一系列的操作,牵扯到多个连续操作,如何保障不会重复操作?
业务分析
多个客户端有可能同时操作同一组数据,并且该数据一旦被操作修改后,将不适用于继续操作
在操作之前锁定要操作的数据,一旦发生变化,终止当前操作

解决方案
? 对 key 添加监视锁,在执行exec前如果key发生了变化,终止事务执行

watch key1 [key2……] 

取消对所有 key 的监视

unwatch

演示如下,此为第二个客户端,在第一个客户端的开启事务执行

127.0.0.1:6379> set name 123
OK
127.0.0.1:6379>
27.0.0.1:6379> watch name
OK
127.0.0.1:6379> get name
"n2"
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set aa bb
QUEUED
127.0.0.1:6379> get aa
QUEUED
127.0.0.1:6379> exec
1) OK
2) "bb"
127.0.0.1:6379> watch name age
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set aa cc
QUEUED
127.0.0.1:6379> get aa
QUEUED
127.0.0.1:6379> exec
(nil)
127.0.0.1:6379>

 不能在事务中开启watch

127.0.0.1:6379> WATCH name
OK
127.0.0.1:6379> get name
"123"
127.0.0.1:6379> UNWATCH
OK
127.0.0.1:6379>

基于特定条件的事务执行——分布式锁
解决方案
使用 setnx 设置一个公共锁 

127.0.0.1:6379> set num 10
OK
127.0.0.1:6379> SETNX lock 1
(integer) 1
127.0.0.1:6379> INCRBY num -1
(integer) 9
127.0.0.1:6379> del lock
(integer) 1
127.0.0.1:6379> get num
"9"
127.0.0.1:6379>

演示先锁在释放20秒

127.0.0.1:6379> set name 123
OK
127.0.0.1:6379> SETNX lock 1
(integer) 1
127.0.0.1:6379> EXPIRE lock 20
(integer) 1
127.0.0.1:6379> get name
"123"
127.0.0.1:6379> del lock
(integer) 1
127.0.0.1:6379> setnx lock-name 1
(integer) 1
127.0.0.1:6379> EXPIRE lock-name 10
(integer) 1
127.0.0.1:6379>
127.0.0.1:6379> setnx lock-name 1
(integer) 0
127.0.0.1:6379> setnx lock-name 1
(integer) 0
127.0.0.1:6379> setnx lock-name 1
(integer) 0
127.0.0.1:6379> setnx lock-name 1
(integer) 1
127.0.0.1:6379>

利用setnx命令的返回值特征,有值则返回设置失败,无值则返回设置成功
    对于返回设置成功的,拥有控制权,进行下一步的具体业务操作
    对于返回设置失败的,不具有控制权,排队或等待
操作完毕通过del操作释放锁
注意:上述解决方案是一种设计概念,依赖规范保障,具有风险性

使用 expire 为锁key添加时间限定,到时不释放,放弃锁
由于操作通常都是微秒或毫秒级,因此该锁定时间不宜设置过大。具体时间需要业务测试后确认。

expire lock-key second
pexpire lock-key milliseconds 

    例如:持有锁的操作最长执行时间127ms,最短执行时间7ms。
    测试百万次最长执行时间对应命令的最大耗时,测试百万次网络延迟平均耗时
    锁时间设定推荐:最大耗时*120%+平均网络延迟*110%
    如果业务最大耗时<<网络平均延迟,通常为2个数量级,取其中单个耗时较长即可

假如在没有执行expire的时候,redis的服务器宕机的话,也会造成死锁,从2.8版本以后,加入了set指令的扩展参数,

setnx和expire指令可以一起执行了,可以解决分布式锁的乱象。

127.0.0.1:6379> set lock:code true ex 5 nx
OK
127.0.0.1:6379> get lock:code
(nil)

Redis的事务

标签:账户   自己   card   set   mil   png   不同   exec   nts   

原文地址:https://www.cnblogs.com/dalianpai/p/12581813.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有 京ICP备13008772号-2
迷上了代码!