目录

  • Redis 事务
    • 一、Redis事务的概念:
    • 二、redis事务提出的逻辑:
    • 三、redis事务的基本操作
    • 四、事务的执行流程
    • 五、redis锁
    • 六、redis分布式锁

Redis 事务

一、Redis事务的概念:

Redis 事务的本质是一组命令的集合。事务支持一次执行多个命令,一个事务中所有命令都会被序列化。在事务执行过程,会按照顺序串行化执行队列中的命令,其他客户端提交的命令请求不会插入到事务执行命令序列中。
总结说:redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。


上图说明:
假如现在有两个客户端,对同一条数据进行操作,客户端1set了一条数据,完了之后另外一个客户端2更改了这个数据,但是客户端1去get数据时发现获取的值跟自己set的值不一样,是客户端2set的值
针对这样的问题,提出了redis事务

二、redis事务提出的逻辑:

基于上面的问题,那我在一个客户端操作的时候,把所有的指令一次性按照顺序排他的放在一个队列中,执行完了之后再让其他的客户端操作

三、redis事务的基本操作

  • 开启事务

     multi 

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

  • 执行事务

    exec 

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

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

    但是你在命令入队列的时候,发现你有些命令指令输入错误,你不想执行了,这个时候,你不想提交事务了

  • 取消事务

    discard

    作用:终止当前事务的定义,发生在multi之后,exec之前

    遇到multi指令,创建队列,遇到discard指令销毁队列

    若在事务队列中存在命令性错误(类似于java编译性错误),则执行EXEC命令时,所有命令都不会执行

    若在事务队列中存在语法性错误(类似于java的1/0的运行时异常),则执行EXEC命令时,其他正确命令会被执行,错误命令抛出异常。

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

四、事务的执行流程

五、redis锁

业务场景
天猫双11热卖过程中,对已经售罄的货物追加补货,4个业务员都有权限进行补货。补货的操作可能是一系 列的操作,牵扯到多个连续操作,如何保障不会重复操作?

业务分析

  • 多个客户端有可能同时操作同一组数据,并且该数据一旦被操作修改后,将不适用于继续操作
  • 在操作之前锁定要操作的数据,一旦发生变化,终止当前操作

也就是说当有很多个业务员同时对补货key进行操作的时候,我们对这个补货Key进行监控,如果有变动说明有其他的业务员(客户端)已经对补货key这个进行了操作,那么其他人不需要修改,如果没有变动事务执行成功

  • 对 key 添加监视锁,在执行exec前如果key发生了变化,终止事务执行
    watch key1 [key2……] 
  • 取消对所有 key 的监视
    unwatch

使用watch检测balance,事务期间balance数据未变动,事务执行成功

使用watch检测balance,在开启事务后(标注1处),在新窗口执行标注2中的操作,更改balance的值,模拟其他客户端在事务执行期间更改watch监控的数据,然后再执行标注1后命令,执行EXEC后,事务未成功执行。

  • 一但执行 EXEC 开启事务的执行后,无论事务使用执行成功, WARCH 对变量的监控都将被取消。
  • 故当事务执行失败后,需重新执行WATCH命令对变量进行监控,并开启新的事务进行操作。

六、redis分布式锁

业务场景:
还是上面补货的问题,现在业务员现在已经补货完了,商品热卖,3秒内销售一空,怎么避免最后一件商品不被多人同时购买?
如果使用上面的锁机制(watch),监控这个补货key有没有改变,那是不行的,一旦补货key一变化事务就执行失败,这样的话其他的用户也不能在后面买到,所以这样也是行不通的
虽然redis是单线程的,但是多个客户端对同一数据同时进行操作时,如何避免不被同时修改?

基于这样的问题,提出了redis分布式锁,你加一把锁,每一个用户过来的时候都需要获取这把锁,只有获取这把锁的时候才能操作成功,没有获取锁的话,操作失败。

redis分布式锁的解决方案

  • 使用 setnx 设置一个公共锁
    setnx lock-key value 

利用setnx命令的返回值特征,有值则返回设置失败,无值则返回设置成功

  • 对于返回设置成功的,拥有控制权,进行下一步的具体业务操作
  • 对于返回设置失败的,不具有控制权,排队或等待
    操作完毕通过del操作释放锁

但是如果一个用户获取了这把锁一直不释放,那怎么办呢?后面的用户一直等嘛?
解决方案

  • 使用 expire 为锁key添加时间限定,到时不释放,放弃锁
     expire lock-key secondpexpire lock-key milliseconds 

由于操作通常都是微秒或毫秒级,因此该锁定时间不宜设置过大。具体时间需要业务测试后确认。

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