2021- 高并发下秒杀商品，你必须知道的9 个细节
2021- 高并发下秒杀商品，你必须知道的9 个细节
高并发下如何设计秒杀系统？这是一个高频面试题。这个问题看似简单，但是里面的水很深，它考查的是高并发场景下，从前端到后端多方面的知识。
瞬时高并发
一般在秒杀时间点（比如：
正常情况下，大部分用户会收到商品已经抢完的提醒，收到该提醒后，他们大概率不会在那个活动页面停留了，如此一来，用户并发量又会急剧下降。所以这个峰值持续的时间其实是非常短的，这样就会出现瞬时高并发的情况，下面用一张图直观的感受一下流量的变化：
像这种瞬时高并发的场景，传统的系统很难应对，我们需要设计一套全新的系统。可以从以下几个方面入手：
- 页面静态化
CDN 加速- 缓存
MQ 异步处理- 限流
- 分布式锁
页面静态化
活动页面是用户流量的第一入口，所以是并发量最大的地方。如果这些流量都能直接访问服务端，恐怕服务端会因为承受不住这么大的压力，而直接挂掉。
活动页面绝大多数内容是固定的，比如：商品名称、商品描述、图片等。为了减少不必要的服务端请求，通常情况下，会对活动页面做静态化处理。用户浏览商品等常规操作，并不会请求到服务端。只有到了秒杀时间点，并且用户主动点了秒杀按钮才允许访问服务端。
这样能过滤大部分无效请求。但只做页面静态化还不够，因为用户分布在全国各地，有些人在北京，有些人在成都，有些人在深圳，地域相差很远，网速各不相同。如何才能让用户最快访问到活动页面呢？这就需要使用
使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。
秒杀按钮
大部分用户怕错过秒杀时间点，一般会提前进入活动页面。此时看到的秒杀按钮是置灰，不可点击的。只有到了秒杀时间点那一时刻，秒杀按钮才会自动点亮，变成可点击的。但此时很多用户已经迫不及待了，通过不停刷新页面，争取在第一时间看到秒杀按钮的点亮。
从前面得知，该活动页面是静态的。那么我们在静态页面中如何控制秒杀按钮，只在秒杀时间点时才点亮呢？没错，使用
看到这里，有些聪明的小伙伴，可能会问：
当秒杀开始的时候系统会生成一个新的
此外，前端还可以加一个定时器，控制比如：
读多写少
在秒杀的过程中，系统一般会先查一下库存是否足够，如果足够才允许下单，写数据库。如果不够，则直接返回该商品已经抢完。由于大量用户抢少量商品，只有极少部分用户能够抢成功，所以绝大部分用户在秒杀时，库存其实是不足的，系统会直接返回该商品已经抢完。
这是非常典型的：读多写少的场景。
如果有数十万的请求过来，同时通过数据库查缓存是否足够，此时数据库可能会挂掉。因为数据库的连接资源非常有限，比如：MySql，无法同时支持这么多的连接。而应该改用缓存，比如：Redis；即便用了
缓存问题
通常情况下，我们需要在
根据商品
这个过程表面上看起来是
缓存击穿
比如商品
如何解决这个问题呢？这就需要加锁，最好使用分布式锁。
当然，针对这种情况，最好在项目启动之前，先把缓存进行预热。即事先把所有的商品，同步到缓存中，这样商品基本都能直接从缓存中获取到，就不会出现缓存击穿的问题了。
是不是上面加锁这一步可以不需要了？表面上看起来，确实可以不需要。但如果缓存中设置的过期时间不对，缓存提前过期了，或者缓存被不小心删除了，如果不加速同样可能出现缓存击穿。其实这里加锁，相当于买了一份保险。
缓存穿透
如果有大量的请求传入的商品
但很显然这些请求的处理性能并不好，有没有更好的解决方案？这时可以想到布隆过滤器。
系统根据商品
这就要求，如果缓存中数据有更新，则要及时同步到布隆过滤器中。如果数据同步失败了，还需要增加重试机制，而且跨数据源，能保证数据的实时一致性吗？显然是不行的。
所以布隆过滤器绝大部分使用在缓存数据更新很少的场景中。如果缓存数据更新非常频繁，又该如何处理呢？这时，就需要把不存在的商品
下次，再有该商品
库存问题
对于库存问题看似简单，实则里面还是有些东西。真正的秒杀商品的场景，不是说扣完库存，就完事了，如果用户在一段时间内，还没完成支付，扣减的库存是要加回去的。
所以，在这里引出了一个预扣库存的概念，预扣库存的主要流程如下：
扣减库存中除了上面说到的预扣库存和回退库存之外，还需要特别注意的是库存不足和库存超卖问题。
数据库扣减库存
使用数据库扣减库存，是最简单的实现方案了，假设扣减库存的
update product set stock=stock-1 where id=123;
这种写法对于扣减库存是没有问题的，但如何控制库存不足的情况下，不让用户操作呢？这就需要在
int stock = mapper.getStockById(123);
if(stock > 0) {
int count = mapper.updateStock(123);
if(count > 0) {
addOrder(123);
}
}
大家有没有发现这段代码的问题？没错，查询操作和更新操作不是原子性的，会导致在并发的场景下，出现库存超卖的情况。有人可能会说，这样好办，加把锁，不就搞定了，比如使用
update product set stock=stock-1 where id=product and stock > 0;
在
Redis 扣减库存
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 ，表示成功。
估计很多小伙伴，一开始都会按这样的思路写代码。但如果仔细想想会发现，这段代码有问题。如果在高并发下，有多个请求同时查询库存，当时都大于
当然有人可能会说，加个
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;
加
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 ，表示成功。
但如果在高并发场景中，有多个请求同时扣减库存，大多数请求的
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 ，是直接返回，表示库存不足。
分布式锁
之前我提到过，在秒杀的时候，需要先从缓存中查商品是否存在，如果不存在，则会从数据库中查商品。如果数据库中，则将该商品放入缓存中，然后返回。如果数据库中没有，则直接返回失败。大家试想一下，如果在高并发下，有大量的请求都去查一个缓存中不存在的商品，这些请求都会直接打到数据库。数据库由于承受不住压力，而直接挂掉。
那么如何解决这个问题呢？这就需要用
setNx 加锁
使用
if (jedis.setnx(lockKey, val) == 1) {
jedis.expire(lockKey, timeout);
}
用该命令其实可以加锁，但和后面的设置超时时间是分开的，并非原子操作。假如加锁成功了，但是设置超时时间失败了，该
那么，有没有保证原子性的加锁命令呢？
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：过期时间
由于该命令只有一步，所以它是原子操作。
释放锁
接下来，有些朋友可能会问：在加锁时，既然已经有了
答：
if (jedis.get(lockKey).equals(requestId)) {
jedis.del(lockKey);
return true;
}
return false;
在释放锁的时候，只能释放自己加的锁，不允许释放别人加的锁。这里为什么要用
答：如果用
if redis.call('get', KEYS[1]) == ARGV[1] then
return redis.call('del', KEYS[1])
else
return 0
end
它能保证查询锁是否存在和删除锁是原子操作。
自旋锁
上面的加锁方法看起来好像没有问题，但如果你仔细想想，如果有
答：每
如何解决这个问题呢？
答：使用自旋锁。
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;
在规定的时间，比如
redisson
除了上面的问题之外，使用
MQ 异步处理
我们都知道在真实的秒杀场景中，有三个核心流程：
而这三个核心流程中，真正并发量大的是秒杀功能，下单和支付功能实际并发量很小。所以，我们在设计秒杀系统时，有必要把下单和支付功能从秒杀的主流程中拆分出来，特别是下单功能要做成
于是，秒杀后下单的流程变成如下：
如果使用
消息丢失问题
秒杀成功了，往
那么，如何防止消息丢失呢？答：加一张消息发送表。
在生产者发送
这时候，要如何处理呢？答：使用
用
重复消费问题
本来消费者消费消息时，在
那么，如何解决重复消息问题呢？答：加一张消息处理表。
消费者读到消息之后，先判断一下消息处理表，是否存在该消息，如果存在，表示是重复消费，则直接返回。如果不存在，则进行下单操作，接着将该消息写入消息处理表中，再返回。
有个比较关键的点是：下单和写消息处理表，要放在同一个事务中，保证原子操作。
垃圾消息问题
这套方案表面上看起来没有问题，但如果出现了消息消费失败的情况。比如：由于某些原因，消息消费者下单一直失败，一直不能回调状态变更接口，这样
那么，如何解决这个问题呢？
每次在
这样如果出现异常，只会产生少量的垃圾消息，不会影响到正常的业务。
延迟消费问题
通常情况下，如果用户秒杀成功了，下单之后，在
我们首先想到的可能是
还有更好的方案？答：使用延迟队列。我们都知道
下单时消息生产者会先生成订单，此时状态为待支付，然后会向延迟队列中发一条消息。达到了延迟时间，消息消费者读取消息之后，会查询该订单的状态是否为待支付。如果是待支付状态，则会更新订单状态为取消状态。如果不是待支付状态，说明该订单已经支付过了，则直接返回。
还有个关键点，用户完成支付之后，会修改订单状态为已支付。
如何限流？
通过秒杀活动，如果我们运气爆棚，可能会用非常低的价格买到不错的商品（这种概率堪比买福利彩票中大奖
如果是我们手动操作，一般情况下，一秒钟只能点击一次秒杀按钮。
但是如果是服务器，一秒钟可以请求成上千接口。
目前有两种常用的限流方式：
- 基于
Nginx 限流 - 基于
Redis 限流
对同一用户限流
为了防止某个用户，请求接口次数过于频繁，可以只针对该用户做限制。
限制同一个用户
对同一ip 限流
有时候只对某个用户限流是不够的，有些高手可以模拟多个用户请求，这种
限制同一个
对接口限流
别以为限制了用户和
在高并发场景下，这种限制对于系统的稳定性是非常有必要的。但可能由于有些非法请求次数太多，达到了该接口的请求上限，而影响其他的正常用户访问该接口。看起来有点得不偿失。
加验证码
相对于上面三种方式，加验证码的方式可能更精准一些，同样能限制用户的访问频次，但好处是不会存在误杀的情况。
通常情况下，用户在请求之前，需要先输入验证码。用户发起请求之后，服务端会去校验该验证码是否正确。只有正确才允许进行下一步操作，否则直接返回，并且提示验证码错误。此外，验证码一般是一次性的，同一个验证码只允许使用一次，不允许重复使用。
普通验证码，由于生成的数字或者图案比较简单，可能会被破解。优点是生成速度比较快，缺点是有安全隐患。还有一个验证码叫做：移动滑块，它生成速度比较慢，但比较安全，是目前各大互联网公司的首选。
提高业务门槛
上面说的加验证码虽然可以限制非法用户请求，但是有些影响用户体验。用户点击秒杀按钮前，还要先输入验证码，流程显得有点繁琐，秒杀功能的流程不是应该越简单越好吗？其实，有时候达到某个目的，不一定非要通过技术手段，通过业务手段也一样。
回到这里，我们通过提高业务门槛，比如只有会员才能参与秒杀活动，普通注册用户没有权限。或者，只有等级到达