十三、利用分布式锁解决超卖问题

库存超卖问题

对于商城系统。超卖了一部分可以补获，12306对超卖问题更敏感。

JMeter的使用

 超卖演示&使用JMeter对购票功能进行压测

 使用synchronized是否能解决库存超卖？

超卖问题出现原因：

 假设余票为1，此时多个线程同时查询到这条余票记录，并进行扣减，那么则会导致超卖发生。

public synchronized void doConfirm(ConfirmOrderDoReq req)

加锁会导致吞吐量/TPS变低，即：售卖效率不高。

一个节点可以加锁，1万个节点呢？还是无法解决超卖。（加节点可以解决性能问题）

存在问题

• 会导致售卖效率不高(可以容忍)
• 在多节点的情况下，还是会出现超卖(不能容忍)。
• 多个人抢多个车次也不应该受影响。

使用Redis分布式锁能否解决库存超卖？

解决超卖：所有节点都能得到的锁

可以通过数据库加锁，性能不高。

所以用redis加锁。

第一个线程进来setIfAbsent设置为true，此时其他线程不可入。

1 String key = req.getDate() + "-" + req.getTrainCode();
2         Boolean setIfAbsent = redisTemplate.opsForValue().setIfAbsent(key, key, 3600, TimeUnit.SECONDS);
3         if (setIfAbsent) {
4             LOG.info("恭喜，抢到锁啦!");
5         } else {
6             LOG.info("很遗憾，没有抢到锁");
7             throw new BusinessException(BusinessExceptionEnum.CONFIRM_ORDER_LOCK_FAIL);
8         }

key就用日期加车次号，value随意。没抢到有提示。

新的问题：

某一处出现异常会怎么样？必须过了超时时间才能进新的请求。

可以在方法结尾删除锁  redisTemplate.delete(lockKey);  

只能解决正常流程问题，异常还有待处理。

将整个set锁以下的部分加异常处理。

1 Boolean setIfAbsent = redisTemplate.opsForValue().setIfAbsent(lockKey, lockKey, 5, TimeUnit.SECONDS);
2         if (setIfAbsent) {
3             LOG.info("恭喜，抢到锁啦!");
4         } else {
5             LOG.info("很遗憾，没有抢到锁");
6             throw new BusinessException(BusinessExceptionEnum.CONFIRM_ORDER_LOCK_FAIL);
7         }

如果这部分也加了锁，没抢到锁也会抛异常，会把别人的锁给删掉。

• 加锁的动作不要放在try里
• 加锁时，将当前线程ID放到锁对应的value中，删除时，先去获取value，比对value值和当前线程ID一致时才能删除。

使用Redisson看门狗解决超时问题

之前的方法就是setnx命令。

最关键的问题是有超时时间，如果项目很大，卡住线程，锁释放掉，还会引起超卖问题。

设置守护线程(看门狗)，不断重置超时时间。

使用守护线程的好处是会随主线程的结束而结束，所以不会出现一直重置成60s，永不过期的问题。

Redis红锁是什么

看门狗锁还会遇到redis宕机问题。

第1个线程拿到锁，redis宕机。第二个线程进来也会拿到锁。

如果有A B C D E台redis（不是集群），第1个线程进来拿到A B C，拿到半数以上的节点，就认为拿到了锁。要求必须是奇数台redis。

RedissonRedLock。