基于redis实现分布式锁

字数 1216阅读 757

最近在负责一个礼品卡模块,就是用返利获得的余额,在APP端兑换不同面值的礼品卡,用于购物使用,类似于现金券。业务很简单
,流程很简单,但是查询更新操作有好几个,可以肯定的是这些操作必须要在一个事务执行,失败必须回滚的。刚开始做的时候傻傻的以为同一个事务并发问题也不会有。功能做完之后,写了个测试用例,启20个线程同事去兑换礼品卡,结果发现有同一张礼品卡被兑换多次的问题。很明显的并发问题,多个线程获取到同一张未兑换的礼品卡。这个问题的原因是先查数据库获取未兑换的卡,这种做法肯定是不太好,即使同步去做,也需要进行一次查库,非常不必要。设想在礼品卡导入的时候,可以把礼品卡放入一个池子中,每次兑换的时候取走一个,这个方式还是比较好实现的,前提池子肯定也得保证线程安全。

废话了挺多,还是接着说下刚刚的问题,首先想到了jvm的同步方法,然后在方法或者需要同步的代码块上加上synchronized,然后还是开启20个线程继续测试,想象挺好,但是突然发现刚刚的问题怎么还是存在。一开始有点百思不得其姐。。咳咳,是解,不要想远了。都已经同步了,为什么还是会出现这种情况呢。想了想突然意识到,不管是同步代码块,还是同步方法,都是在@Transactional注解的方法下。线程释放锁的时候,也许AOP的事务处理,并未提交成功,然后另一个线程就拿到了钥匙。获取到了上个事务同一个未兑换的礼品卡,导致了这个现象出现。随即又写了个方法,在方法中写上同步代码块,调用事务方法,结果没有出现上面的情况。感觉猜想应该是正确的吧。。

问题虽然解决了一些,但是另一个问题接着就来了。。预生产,线上并非部署一个实例,如果使用jvm的同步方法,还是有一定几率出现并发问题,这就想到了分布式锁。之前一直听说,也没有实现过,马上网上搜罗了一下。
一般的解决方案如下:

  1. zookeeper分布式锁,基于自增节点
  2. memcache分布式锁,基于add函数
  3. Redis分布式锁,基于setnx命令【本次使用】

说下分布式锁的基本功能:

  • 同一时刻只能存在一个锁
  • 需要解决意外死锁问题,也就是锁能超时自动释放
  • 支持主动释放锁

下面说下我的实现思路,通过注解的方式,定义方法注解,然后通过Spring 的AOP方式,在方法执行前加锁,方法执行后释放锁。

使用框架:
springboot + redis 集群

具体代码如下:
1.编写方法注解

Paste_Image.png

在方法上使用此注解,就会被AOP拦截,并进行加锁处理。

2.编写方法参数上的注解


Paste_Image.png

该注解的作用,主要是影响redis中锁的key。

3.在需要调用的方法使用注解

Paste_Image.png

我这里使用的模块礼品卡,然后redis的锁的轮训时间为5s。用礼品卡的库存ID,当做唯一锁key。这样做,不同库存ID,或者说不同类型的礼品卡就是不同的锁,也会提高一些并发。

4.spring AOP 拦截是实现

Paste_Image.png

这里主要做的就是获取获取注解的值,和注解的参数的值,然后创建锁对象获取锁。然后执行方法,最后在finally中释放锁。还是很简单的

5.redis获取锁的主要实现

Paste_Image.png

这里通过不断的轮询,从redis获取锁。如果未获取到,怎返回false,业务处获取false直接抛异常。主要是通过redis的setNx方法实现分布式锁。删除锁的代码很简单,就是del,这里不展示了。

这里只是简单的实现了下,后续再继续完善。

推荐阅读更多精彩内容