2023春招面试专题:高并发解决方案(二)

本文涉及的产品
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
简介: 2023春招面试专题:高并发解决方案

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. 先判断该用户有没有秒杀过该商品,如果已经秒杀过,则直接返回-1。
  2. 查询库存,如果库存小于等于0,则直接返回0,表示库存不足。
  3. 如果库存充足,则扣减库存,然后将本次秒杀记录保存起来。然后返回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. 先判断该用户有没有秒杀过该商品,如果已经秒杀过,则直接返回-1。
  2. 扣减库存,判断返回值是否小于0,如果小于0,则直接返回0,表示库存不足。
  3. 如果扣减库存后,返回值大于或等于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;");

该代码的主要流程如下:

  1. 先判断商品id是否存在,如果不存在则直接返回。
  2. 获取该商品id的库存,判断库存如果是-1,则直接返回,表示不限制库存。
  3. 如果库存大于0,则扣减库存。
  4. 如果库存等于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


相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore &nbsp; &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&amp;RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
2月前
|
缓存 NoSQL 关系型数据库
|
2月前
|
存储 缓存 监控
美团面试:说说OOM三大场景和解决方案? (绝对史上最全)
小伙伴们,有没有遇到过程序突然崩溃,然后抛出一个OutOfMemoryError的异常?这就是我们俗称的OOM,也就是内存溢出 本文来带大家学习Java OOM的三大经典场景以及解决方案,保证让你有所收获!
166 0
美团面试:说说OOM三大场景和解决方案? (绝对史上最全)
|
3月前
|
消息中间件 安全 NoSQL
2023春招面试专题:高并发解决方案(三)
2023春招面试专题:高并发解决方案
|
1月前
|
存储 缓存 监控
2024年春招小红书前端实习面试题分享
春招已经拉开帷幕啦! 春招的拉开,意味着新一轮的求职大战已经打响,希望每位求职者都能充分准备,以最佳的状态迎接挑战,找到心仪的工作,开启职业生涯的新篇章。祝愿每位求职者都能收获满满,前程似锦!
71 3
|
1月前
|
消息中间件 NoSQL Java
春招开始,面试也多起来了
春招开始,面试也多起来了
43 0
春招开始,面试也多起来了
|
3月前
|
算法 Java 程序员
阿里P8大佬终于把春招面试必备的神级Java面试手册给开源了!
先说说Java Java 作为国人编程开发语言中的 NO.1,已经占比半壁江山,选择入行做 IT 做编程开发的人,基本都把它作为首选语言,进大厂拿高薪也是大多数小伙伴们的梦想。 以前Java 岗位人才的空缺,而需求量又大,所以这种人才供不应求的现状,就是 Java 工程师的薪资待遇相对优厚的原因所在。 但是随着这个从事行业的人数逐渐增多,行业竞争也越来越大,招聘的企业和程序员们都想招聘到自己需要的人才/找到自己理想的岗位,国内大厂尤其是阿里招聘Java岗位居多,导致现在 Java 面试越来越难,内卷早就是大势所趋,万物皆可卷,卷的我们都见怪不怪了。 那么,阿里Java面试难度大吗?
|
25天前
|
Java 程序员
java线程池讲解面试
java线程池讲解面试
43 1
|
2月前
|
存储 关系型数据库 MySQL
2024年Java秋招面试必看的 | MySQL调优面试题
随着系统用户量的不断增加,MySQL 索引的重要性不言而喻,对于后端工程师,只有在了解索引及其优化的规则,并应用于实际工作中后,才能不断的提升系统性能,开发出高性能、高并发和高可用的系统。 今天小编首先会跟大家分享一下MySQL 索引中的各种概念,然后介绍优化索引的若干条规则,最后利用这些规则,针对面试中常考的知识点,做详细的实例分析。
245 0
2024年Java秋招面试必看的 | MySQL调优面试题
|
2月前
|
存储 算法 Java
铁子,你还记得这些吗----Java基础【拓展面试常问题型】
铁子,你还记得这些吗----Java基础【拓展面试常问题型】
46 1
|
2月前
|
NoSQL Java 关系型数据库
凭借Java开发进阶面试秘籍(核心版)逆流而上
最近参加了面试或者身边有朋友在面试的兄弟有没有发现,现在的面试不仅会问八股文,还会考察框架、项目实战、算法数据结构等等,需要准备的越来越多。 其实面试的时候,并不是要求你所有的知识点都会,而是关键的问题答到点子上!这份《Java 开发进阶面试秘籍(核心版)》由 P8 面试官整体把控,目前已经更新了 30 万字! 资料中涵盖了一线大厂、中小厂面试真题,毕竟真题都是技术领域最经典的基础知识和经验沉淀的汇总,非常有必要学习掌握!双重 buff 叠加,offer 接到手软~ 点击此处取,这可能是你到目前为止领取的最具含金量的一份资料! 整套资料涵盖:Spring、Spring