秒杀系统实战系列（十）防止商品超卖

在上一篇文章《秒杀系统实战系列（九）编写基本的秒杀核心代码》我们已经编写了秒杀的核心逻辑代码，同时我们也演示了秒杀的请求，但是既然是秒杀环节，那么我们肯定是有并发请求需求的，所以我们使用apipost工具并发测试下，首先我们把商品的库存设置为10个：

然后我们用工具进行并发测试，起50个线程，并发测试10轮：

然后经过一段时间的并发工具的测试结果：

可以看到并发请求是没问题的，然后我们看看数据库：

可以看到这里id为1的商品库存变成了负数，这是不是超卖了？在实际的业务中这是绝对不允许的，所以这里我们需要调整下，如何调整防止出现商品超卖的清空呢呢？就是使用分布式锁，在昨天的文章《利用注解的方式使用Redisson分布式锁》我们演示了分布式锁的使用。所以这里我们在当前的秒杀项目里面添加上分布式锁。这里比较简单，主要是在秒杀下单的controller里面添加对应的redislock的注解，示例代码如下：

/**
	 * 秒杀商品的接口
	 * @param userNo
	 * @return
	 */
	@PostMapping("/doSeckill")
	@RedisDistributedLock(key = "'seckill_lock_good_'+#request.goodId", errorDesc = "当前请求频繁，请稍后重试")
	public BaseResponse doSeckill(@RequestHeader("userNo") String userNo,@RequestBody @Validated GoodRequest request) {
		return seckillService.doSeckill(userNo,request.getGoodId());
	}

这里的@RedisDistributedLock注解就是为接口添加分布式锁，添加完毕之后，我们再把库存置为10:

然后再把项目启动起来，然后用apipost进行并发测试：

然后我们再去看商品库存：

看到了吗? 商品库存为0了，不再出现商品超卖的情况了。

备注：

1、这里我们使用的是分布式锁，由于分布式锁会消耗一定的性能，因此对于秒杀环节来说，分布式锁一定要最小粒度话。
2、这里我们没有部署把good-service部署多个实例进行测试，这是因为在编写redisson分布式锁的时候已经用多个实例测试了，没有任何问题。所以可以放心使用。
3、生产环节中千万不能出现超卖的情况。后果很严重。

最后按照惯例，附上本案例的源码，登陆后即可下载。