基于Redisson分布式锁解决秒杀系统的“超卖”问题

本文主要是介绍基于Redisson分布式锁解决秒杀系统的“超卖”问题，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

作者：钟林森，出版书籍：《分布式中间件技术实战Java版》《Spring Boot企业级项目开发-入门到精通》

Redisson，字如其名，是搭建在缓存中间件Redis基础上的一款综合中间件，除了拥有Redis本身提供的强大功能外，还提供了诸如分布式锁、分布式服务、延迟队列、远程调用等强大的功能。

从名字上就可以看出来：Redis + son，犹如Redis的儿子，儿子不仅继承了老爸强大的血脉，而且还自己修炼、发展出了属于自己的一套本领…..

Redisson开源地址为https://github.com/redisson/redisson/wiki/目录

△ Redisson官网首页截图

本文我们将使用中间件Redisson中强大的功能组件“分布式锁”，来解决高并发下多线程导致的超卖以及重复秒杀等安全问题。

在正文开始之前，先来解决一个问题：为什么要用Redisso，而不是Redis？

相较于原生Redis的SetNX+Expire实现的分布式锁而言，Redisson的分布式锁组件可以解决原生Redis组合命令带来的一些缺陷，即在执行SetNX命令之后，在还没来得及执行Expire操作之前，如果此时Redis的服务器节点恰好出现宕机或者服务不能用的情况，那将会导致相应的Key永远存于缓存中，即处于所谓的“永久被锁死”的状态！

而Redisson的分布式锁则可以很好地解决这种问题，其底层的实现机制在于：Redisson内部提供了一个监控锁的看门狗WatchDog，其作用在于Redis实例被关闭之前，不断延长锁的有效期。除此之外，Redisson还通过加锁的方法提供了leaseTime等参数来指定加锁的有效时间，即超过这个时间后“锁”便自动解开了。

下面我们将加入相关的依赖Jar及其配置，使用“分布式锁”组件，来解决秒杀过程中出现的“库存超卖”、“重复秒杀”等并发安全问题。

（1）首先，需要加入Redisson的依赖，版本号为3.8.2，如下所示：

<!--redisson-->
<dependency><groupId>org.redisson</groupId><artifactId>redisson</artifactId><version>3.8.2</version>
</dependency>

然后需要在配置文件application.properties中加入Redis服务所在的服务器节点Host、端口Port等信息，如下所示：

redis.config.host=redis://127.0.0.1:6379
spring.redis.password=

（2）紧接着，自定义注入操作组件RedissonClient

其自定义注入Bean组件的源代码如下所示：

@Configuration
public class RedissonConfig {@Autowiredprivate Environment env;@Beanpublic RedissonClient redissonClient(){Config config=new Config();config.useSingleServer().setAddress(env.getProperty("redis.config.host")).setPassword(env.getProperty("spring.redis.password"));RedissonClient client=Redisson.create(config);return client;}
}

（3）前期工作已准备完毕，接下来需要将其应用到秒杀系统中秒杀的核心业务逻辑

在KillService服务类中我们开辟了一个新的处理方法，即killItem，其完整的源码如下所示：

@Autowired
private RedissonClient redissonClient;//秒杀核心业务逻辑的处理-redisson分布式锁
@Override
public Boolean killItem (Integer killId, Integer userId) throws Exception {Boolean result=false;final String lockKey=new StringBuffer().append(killId).append("-RedissonLock").toString();RLock lock=redissonClient.getLock(lockKey);try {//TODO:第一个参数30s=表示尝试获取锁，并且最大等待获取锁的时间为30s//TODO:第二个参数10s=表示上锁之后，10s内操作完毕将自动释放锁Boolean cacheRes=lock.tryLock(30,10,TimeUnit.SECONDS);if (cacheRes){//TODO:核心业务逻辑的处理if (itemKillSuccessMapper.countByKillUserId(killId,userId) <= 0){ItemKill itemKill=itemKillMapper.selectById(killId);if (itemKill!=null && 1==itemKill.getCanKill() && itemKill.getTotal()>0){int res=itemKillMapper.updateKillItem(killId);if (res>0){commonRecordKillSuccessInfo(itemKill,userId);result=true;}}}else{throw new Exception("redisson-您已经抢购过该商品了!");}}}finally {//TODO:释放锁lock.unlock();}return result;
}

从该源代码中，我们主要利用了Redisson分布式锁中的“可重入锁”组件，其使用过程需要经过如下几个步骤：
A．需要尝试去获取锁，其对应的代码以及注释如下所示，

//TODO:第一个参数30s=表示尝试获取分布式锁，并且最大的等待获取锁的时间为30s
//TODO:第二个参数10s=表示上锁之后，10s内操作完毕将自动释放锁
Boolean cacheRes=lock.tryLock(30,10,TimeUnit.SECONDS);

B.在获取到锁之后，即cacheRes=true，即可进入秒杀核心业务代码的执行；同时在处理完成之后，需要释放锁，如下所示：

//TODO:释放锁
lock.unlock();

（4）至此，并发多线程对于共享资源并发访问所出现的并发安全问题的代码实战已经完毕了！

接下来进入压测环节，压测之前设定待秒杀商品的可秒杀总数total=6，并设置随机可选取的用户ID列表的总数为10个，其取值为10040~10049；
在压测完成之后，理论上最好的结果是：total最终变为=0，同时item_kill_success数据库表中有 6 条秒杀成功而生成的订单记录。

此时，我们尝试将线程组中并发的线程数调整为10w，点击启动按钮，稍等片刻，观察控制台的输出信息以及item_kill和item_kill_success这两个数据库表的数据变化情况，并查看其最终的记录结果，如下图所示：