Offer 拿来吧你！秒杀系统？这不是必考的嘛，kafka 与 rabbitmq 面试题
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，是直接返回，表示库存不足。
之前我提到过，在秒杀的时候，需要先从缓存中查商品是否存在，如果不存在，则会从数据库中查商品。如果数据库中，则将该商品放入缓存中，然后返回。如果数据库中没有，则直接返回失败。
大家试想一下，如果
在高并发下，有大量的请求都去查一个缓存中不存在的商品，这些请求都会直接打到数据库。数据库由于承受不住压力，而直接挂掉。
那么如何解决这个问题呢？
这就需要用 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 可以解决，由于篇幅的原因，在这里先保留一点悬念，有疑问的私聊给我。后面会出一个专题介绍分布式锁，敬请期待。
我们都知道在真实的秒杀场景中，有三个核心流程：
而这三个核心流程中，真正并发量大的是秒杀功能，下单和支付功能实际并发量很小。所以，我们在设计秒杀系统时，有必要把下单和支付功能从秒杀的主流程中拆分出来，特别是下单功能要做成 mq 异步处理的。而支付功能，比如支付宝支付，是业务场景本身保证的异步。
于是，秒杀后下单的流程变成如下：
如果使用 mq，需要关注以下几个问题：
8.1 消息丢失问题
秒杀成功了，往 mq 发送下单消息的时候，有可能会失败。原因有很多，比如：网络问题、broker 挂了、mq 服务端磁盘问题等。这些情况，都可能会造成消息丢失。
那么，如何防止消息丢失呢？
答：加一张消息发送表。
在生产者发送 mq 消息之前，先把该条消息写入消息发送表，初始状态是待处理，然后再发送 mq 消息。消费者消费消息时，处理完业务逻辑之后，再回调生产者的一个接口，修改消息状态为已处理。
如果生产者把消息写入消息发送表之后，再发送 mq 消息到 mq 服务端的过程中失败了，造成了消息丢失。
这时候，要如何处理呢？
答：使用 job，增加重试机制。
用 job 每隔一段时间去查询消息发送表中状态为待处理的数据，然后重新发送 mq 消息。
8.2 重复消费问题
本来消费者消费消息时，在 ack 应答的时候，如果网络超时，本身就可能会消费重复的消息。但由于消息发送者增加了重试机制，会导致消费者重复消息的概率增大。
那么，如何解决重复消息问题呢？
答：加一张消息处理表。
消费者读到消息之后，先判断一下消息处理表，是否存在该消息，如果存在，表示是重复消费，则直接返回。如果不存在，则进行下单操作，接着将该消息写入消息处理表中，再返回。
有个比较关键的点是：下单和写消息处理表，要放在同一个事务中，保证原子操作。
8.3 垃圾消息问题
这套方案表面上看起来没有问题，但如果出现了消息消费失败的情况。比如：由于某些原因，消息消费者下单一直失败，一直不能回调状态变更接口，这样 job 会不停的重试发消息。最后，会产生大量的垃圾消息。
那么，如何解决这个问题呢？
每次在 job 重试时，需要先判断一下消息发送表中该消息的发送次数是否达到最大限制，如果达到了，则直接返回。如果没有达到，则将次数加 1，然后发送消息。
这样如果出现异常，只会产生少量的垃圾消息，不会影响到正常的业务。
8.4 延迟消费问题
通常情况下，如果用户秒杀成功了，下单之后，在 15 分钟之内还未完成支付的话，该订单会被自动取消，回退库存。
那么，在 15 分钟内未完成支付，订单被自动取消的功能，要如何实现呢？
我们首先想到的可能是 job，因为它比较简单。
但 job 有个问题，需要每隔一段时间处理一次，实时性不太好。
还有更好的方案？
答：使用延迟队列。
我们都知道 rocketmq，自带了延迟队列的功能。
下单时消息生产者会先生成订单，此时状态为待支付，然后会向延迟队列中发一条消息。达到了延迟时间，消息消费者读取消息之后，会查询该订单的状态是否为待支付。如果是待支付状态，则会更新订单状态为取消状态。如果不是待支付状态，说明该订单已经支付过了，则直接返回。
还有个关键点，用户完成支付之后，会修改订单状态为已支付。
通过秒杀活动，如果我们运气爆棚，可能会用非常低的价格买到不错的商品（这种概率堪比买福利彩票中大奖）。
但有些高手，并不会像我们一样老老实实，通过秒杀页面点击秒杀按钮，抢购商品。他们可能在自己的服务器上，模拟正常用户登录系统，跳过秒杀页面，直接调用秒杀接口。
如果是我们手动操作，一般情况下，一秒钟只能点击一次秒杀按钮。
但是如果是服务器，一秒钟可以请求成上千接口。
这种差距实在太明显了，如果不做任何限制，绝大部分商品可能是被机器抢到，而非正常的用户，有点不太公平。
还未添加个人签名 2021.03.18 加入
还未添加个人简介
评论