2023春招面试专题：高并发解决方案（一）https://developer.aliyun.com/article/1423373
5.1 缓存击穿
比如商品A第一次秒杀时，缓存中是没有数据的，但数据库中有。虽说上面有如果从数据库中查到数据，则放入缓存的逻辑。
然而，在高并发下，同一时刻会有大量的请求，都在秒杀同一件商品，这些请求同时去查缓存中没有数据，然后又同时访问数据库。结果悲剧了，数据库可能扛不住压力，直接挂掉。
如何解决这个问题呢？
这就需要加锁，最好使用分布式锁。
当然，针对这种情况，最好在项目启动之前，先把缓存进行预热。即事先把所有的商品，同步到缓存中，这样商品基本都能直接从缓存中获取到，就不会出现缓存击穿的问题了。
是不是上面加锁这一步可以不需要了？
表面上看起来，确实可以不需要。但如果缓存中设置的过期时间不对，缓存提前过期了，或者缓存被不小心删除了，如果不加速同样可能出现缓存击穿。
其实这里加锁，相当于买了一份保险。
5.2 缓存穿透
如果有大量的请求传入的商品id，在缓存中和数据库中都不存在，这些请求不就每次都会穿透过缓存，而直接访问数据库了。
由于前面已经加了锁，所以即使这里的并发量很大，也不会导致数据库直接挂掉。
但很显然这些请求的处理性能并不好，有没有更好的解决方案？
这时可以想到布隆过滤器。
系统根据商品id，先从布隆过滤器中查询该id是否存在，如果存在则允许从缓存中查询数据，如果不存在，则直接返回失败。
虽说该方案可以解决缓存穿透问题，但是又会引出另外一个问题：布隆过滤器中的数据如何更缓存中的数据保持一致？
这就要求，如果缓存中数据有更新，则要及时同步到布隆过滤器中。如果数据同步失败了，还需要增加重试机制，而且跨数据源，能保证数据的实时一致性吗？
显然是不行的。
所以布隆过滤器绝大部分使用在缓存数据更新很少的场景中。
如果缓存数据更新非常频繁，又该如何处理呢？
这时，就需要把不存在的商品id也缓存起来。
下次，再有该商品id的请求过来，则也能从缓存中查到数据，只不过该数据比较特殊，表示商品不存在。需要特别注意的是，这种特殊缓存设置的超时时间应该尽量短一点。
6 库存问题
对于库存问题看似简单，实则里面还是有些东西。
真正的秒杀商品的场景，不是说扣完库存，就完事了，如果用户在一段时间内，还没完成支付，扣减的库存是要加回去的。
所以，在这里引出了一个预扣库存的概念，预扣库存的主要流程如下：
扣减库存中除了上面说到的预扣库存和回退库存之外，还需要特别注意的是库存不足和库存超卖问题。
6.1 数据库扣减库存
使用数据库扣减库存，是最简单的实现方案了，假设扣减库存的sql如下：
update product set stock=stock-1 where id=123;
这种写法对于扣减库存是没有问题的，但如何控制库存不足的情况下，不让用户操作呢？
这就需要在update之前，先查一下库存是否足够了。
伪代码如下：
int stock = mapper.getStockById(123); if(stock > 0) { int count = mapper.updateStock(123); if(count > 0) { addOrder(123); } }
大家有没有发现这段代码的问题？
没错，查询操作和更新操作不是原子性的，会导致在并发的场景下，出现库存超卖的情况。
有人可能会说，这样好办，加把锁，不就搞定了，比如使用synchronized关键字。
确实，可以，但是性能不够好。
还有更优雅的处理方案，即基于数据库的乐观锁，这样会少一次数据库查询，而且能够天然的保证数据操作的原子性。
只需将上面的sql稍微调整一下：
update product set stock=stock-1 where id=product and stock > 0;
在sql最后加上：stock > 0，就能保证不会出现超卖的情况。
但需要频繁访问数据库，我们都知道数据库连接是非常昂贵的资源。在高并发的场景下，可能会造成系统雪崩。而且，容易出现多个请求，同时竞争行锁的情况，造成相互等待，从而出现死锁的问题。
6.2 redis扣减库存
redis的incr方法是原子性的，可以用该方法扣减库存。伪代码如下：
boolean exist = redisClient.query(productId,userId); if(exist) { return -1; } int stock = redisClient.queryStock(productId); if(stock <=0) { return 0; } redisClient.incrby(productId, -1); redisClient.add(productId,userId); return 1;
代码流程如下：
- 先判断该用户有没有秒杀过该商品，如果已经秒杀过，则直接返回-1。
- 查询库存，如果库存小于等于0，则直接返回0，表示库存不足。
- 如果库存充足，则扣减库存，然后将本次秒杀记录保存起来。然后返回1，表示成功。
估计很多小伙伴，一开始都会按这样的思路写代码。但如果仔细想想会发现，这段代码有问题。
有什么问题呢？
如果在高并发下，有多个请求同时查询库存，当时都大于0。由于查询库存和更新库存非原则操作，则会出现库存为负数的情况，即库存超卖。
当然有人可能会说，加个synchronized不就解决问题？
调整后代码如下：
boolean exist = redisClient.query(productId,userId); if(exist) { return -1; } synchronized(this) { int stock = redisClient.queryStock(productId); if(stock <=0) { return 0; } redisClient.incrby(productId, -1); redisClient.add(productId,userId); } return 1;
加synchronized确实能解决库存为负数问题，但是这样会导致接口性能急剧下降，每次查询都需要竞争同一把锁，显然不太合理。
为了解决上面的问题，代码优化如下：
boolean exist = redisClient.query(productId,userId); if(exist) { return -1; } if(redisClient.incrby(productId, -1)<0) { return 0; } redisClient.add(productId,userId); return 1;
该代码主要流程如下：
- 先判断该用户有没有秒杀过该商品，如果已经秒杀过，则直接返回-1。
- 扣减库存，判断返回值是否小于0，如果小于0，则直接返回0，表示库存不足。
- 如果扣减库存后，返回值大于或等于0，则将本次秒杀记录保存起来。然后返回1，表示成功。
该方案咋一看，好像没问题。
但如果在高并发场景中，有多个请求同时扣减库存，大多数请求的incrby操作之后，结果都会小于0。
虽说，库存出现负数，不会出现超卖的问题。但由于这里是预减库存，如果负数值负的太多的话，后面万一要回退库存时，就会导致库存不准。
那么，有没有更好的方案呢？
6.3 lua脚本扣减库存
我们都知道lua脚本，是能够保证原子性的，它跟redis一起配合使用，能够完美解决上面的问题。
lua脚本有段非常经典的代码：
StringBuilder lua = new StringBuilder(); lua.append("if (redis.call('exists', KEYS[1]) == 1) then"); lua.append(" local stock = tonumber(redis.call('get', KEYS[1]));"); lua.append(" if (stock == -1) then"); lua.append(" return 1;"); lua.append(" end;"); lua.append(" if (stock > 0) then"); lua.append(" redis.call('incrby', KEYS[1], -1);"); lua.append(" return stock;"); lua.append(" end;"); lua.append(" return 0;"); lua.append("end;"); lua.append("return -1;");
该代码的主要流程如下：
- 先判断商品id是否存在，如果不存在则直接返回。
- 获取该商品id的库存，判断库存如果是-1，则直接返回，表示不限制库存。
- 如果库存大于0，则扣减库存。
- 如果库存等于0，是直接返回，表示库存不足。
7 分布式锁
之前我提到过，在秒杀的时候，需要先从缓存中查商品是否存在，如果不存在，则会从数据库中查商品。如果数据库中，则将该商品放入缓存中，然后返回。如果数据库中没有，则直接返回失败。
大家试想一下，如果在高并发下，有大量的请求都去查一个缓存中不存在的商品，这些请求都会直接打到数据库。数据库由于承受不住压力，而直接挂掉。
那么如何解决这个问题呢？
这就需要用redis分布式锁了。
7.1 setNx加锁
使用redis的分布式锁，首先想到的是setNx命令。
if (jedis.setnx(lockKey, val) == 1) { jedis.expire(lockKey, timeout); }
用该命令其实可以加锁，但和后面的设置超时时间是分开的，并非原子操作。
假如加锁成功了，但是设置超时时间失败了，该lockKey就变成永不失效的了。在高并发场景中，该问题会导致非常严重的后果。
那么，有没有保证原子性的加锁命令呢？
7.2 set加锁
使用redis的set命令，它可以指定多个参数。
String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime); if ("OK".equals(result)) { return true; } return false;
其中：
- lockKey：锁的标识
- requestId：请求id
- NX：只在键不存在时，才对键进行设置操作。
- PX：设置键的过期时间为 millisecond 毫秒。
- expireTime：过期时间
由于该命令只有一步，所以它是原子操作。
7.3 释放锁
接下来，有些朋友可能会问：在加锁时，既然已经有了lockKey锁标识，为什么要需要记录requestId呢？
答：requestId是在释放锁的时候用的。
if (jedis.get(lockKey).equals(requestId)) { jedis.del(lockKey); return true; } return false;
在释放锁的时候，只能释放自己加的锁，不允许释放别人加的锁。
这里为什么要用requestId，用userId不行吗？
答：如果用userId的话，假设本次请求流程走完了，准备删除锁。此时，巧合锁到了过期时间失效了。而另外一个请求，巧合使用的相同userId加锁，会成功。而本次请求删除锁的时候，删除的其实是别人的锁了。
当然使用lua脚本也能避免该问题：
if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end
它能保证查询锁是否存在和删除锁是原子操作。
7.4 自旋锁
上面的加锁方法看起来好像没有问题，但如果你仔细想想，如果有1万的请求同时去竞争那把锁，可能只有一个请求是成功的，其余的9999个请求都会失败。
在秒杀场景下，会有什么问题？
答：每1万个请求，有1个成功。再1万个请求，有1个成功。如此下去，直到库存不足。这就变成均匀分布的秒杀了，跟我们想象中的不一样。
如何解决这个问题呢？
答：使用自旋锁。
try { Long start = System.currentTimeMillis(); while(true) { String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime); if ("OK".equals(result)) { return true; } long time = System.currentTimeMillis() - start; if (time>=timeout) { return false; } try { Thread.sleep(50); } catch (InterruptedException e) { e.printStackTrace(); } } } finally{ unlock(lockKey,requestId); } return false;
在规定的时间，比如500毫秒内，自旋不断尝试加锁，如果成功则直接返回。如果失败，则休眠50毫秒，再发起新一轮的尝试。如果到了超时时间，还未加锁成功，则直接返回失败。
7.5 redisson
除了上面的问题之外，使用redis分布式锁，还有锁竞争问题、续期问题、锁重入问题、多个redis实例加锁问题等。
这些问题使用redisson可以解决，由于篇幅的原因，在这里先保留一点悬念，有疑问的私聊给我。后面会出一个专题介绍分布式锁，敬请期待。
8 mq异步处理
我们都知道在真实的秒杀场景中，有三个核心流程：
而这三个核心流程中，真正并发量大的是秒杀功能，下单和支付功能实际并发量很小。所以，我们在设计秒杀系统时，有必要把下单和支付功能从秒杀的主流程中拆分出来，特别是下单功能要做成mq异步处理的。而支付功能，比如支付宝支付，是业务场景本身保证的异步。
于是，秒杀后下单的流程变成如下：
如果使用mq，需要关注以下几个问题：
2023春招面试专题：高并发解决方案（三）https://developer.aliyun.com/article/1423375
