【springboot项目】之秒杀项目常见问题(Seckill)

秒杀问题分为两部分:用户查看商品详情页、用户下单

项目简介:

模拟了高并发场景的商城系统,它具备秒杀功能,为了解决秒杀场景下的高并发问题。引入了 redis 作为缓存中间件,1.主要作用是缓存预热、预减库存等等。2.针对高并发场景进行了页面优化,缓存页面至浏览器,前后端分离降低服务器压力,加快用户访问速度。

先不答:在安全性问题上,我使用双重MD5密码校验,隐藏了秒杀接口地址,设置了接口限流防刷。

最后还使用数学公式验证码不仅可以防恶意刷访问,还起到了削峰的作用。通过 Jmeter 压力 测试 ,系统的QPS从150/s提升到2000/s。

QPS:【Queries-per-second】每秒处理事务数(每秒查询率)

一、查看商品详情页

1.初始化流程图

【springboot项目】之秒杀项目常见问题(Seckill)_第1张图片

介绍:若redis中有数据就把数据返回到前端,若没有数据则请求数据库;

一条查询操作,在service层首先走Redis,若命中直接返回,否则去底层数据库中查,查询到了,返回给service层,并将查询结果保存在redis中,后返回给Controller

问:有无更快一点的方法?

利用多级缓存:查询redis会有网络请求,所以会产生一些i/o带宽的浪费,所以可以考虑把热点数据存储到jvm内存中去(热点数据:基本不变的数据),此时前端请求直接走jvm,没有一些I/O读写的操作,所以速度就会变快一些;若jvm内存中没有数据,再去redis中去查,redis中没有再去数据库查。

注意:但是jvm的内存是非常宝贵的,所以我们只存放非常热点的数据,不经常容易变的数据;

【springboot项目】之秒杀项目常见问题(Seckill)_第2张图片

image-20220722185625155
问:jvm并发有限,比如要抗住10万并发量怎么办?

答:1.利用服务器集群,比如我们一个机器可以抗住1w并发,那么我就可以利用10个机器去解决10万并发的问题;用Nginx来做负载均衡:用上一些轮询算法等(左图所示);**2.**还可以利用缓存来解决,我们把这个缓存放在距离用户最近的地方(这样子系统就会很快,用户体验也会很好),从目前这个流程图看,Nginx是距离用户最近的地方,所以我们可以用Nginx去访问这个redis(下两个图所示)
【springboot项目】之秒杀项目常见问题(Seckill)_第3张图片

【springboot项目】之秒杀项目常见问题(Seckill)_第4张图片

关于优化的问题

问:如商品详情页会有很多静态资源,这些静态资源怎么处理?

答:商品详情页有很多静态资源:比如我们写好的css,jss,html等,若去服务器上请求会浪费性能,这个时候我们可以把这个静态资源缓存到这个CDN上面,然后浏览器就可以直接去CDN上取这个静态资源,此时速度就会提升很多;

关于CDN:cdn优化的是用户访问静态资源的速度;

【springboot项目】之秒杀项目常见问题(Seckill)_第5张图片

问:但是页面上显示的数据还得去后端接口查询出来,而我又不想去后端接口查询数据,如何处理?

答:在后端把页面完全静态化,然后把整个这个静态化好的资源放到CDN上面去,浏览器直接请求CDN上的详情页就可以直接显示了;

再问:那什么是页面静态化呢?

答:后端数据实时得渲染到前端页面上,才能显示不同的页面数据;因为有些商品详情的信息是基本不会发生改变的,页面静态化就是提前把这个数据渲染到页面上,然后把页面提供给用户访问。

【springboot项目】之秒杀项目常见问题(Seckill)_第6张图片

二、秒杀下单

在活动开始之前,提前先把这个商品的库存缓存到redis中去,在redis里面进行一个预减库存的操作。(因为高并发下修改数据库的数据,会引发锁竞争);这样的话就不用频繁的去修改数据库中的数据,也就有效减少了锁竞争的问题

【springboot项目】之秒杀项目常见问题(Seckill)_第7张图片

问:接上:那你是如何保证这个redis和数据库的数据一致性呢?

答:我们在redis和数据库之间加上MQ,用mq异步的方式同步这个信息。也就是说:扣减库存的操作在redis里面执行,然后把扣减库存的信息告诉MQ,然后MQ再通知MySQL扣减了多少库存;

队列排队下单

问:两个小问题
①mysql消费mq失败怎么办?②在数据库中创建订单失败了怎么办?

答:我们可以利用分布式事务来解决一下,如MQ中的rocket mq去解决;(因为rockt mq对事务比较友好)

【springboot项目】之秒杀项目常见问题(Seckill)_第8张图片

问:那么不用mq,且redis挂了怎么办?

答:----(暂未写好答案)

问:一千万人秒杀商品,但是库存只有100w件怎么办?其余的人还在不断地请求我们的系统,这样子好吗?
做了什么流量削峰的措施?秒杀令牌

答:首先这样子肯定不好,一个是对系统的性能有影响,再一个就是用户的体验性不好;

如何解决:我么可以添加一个秒杀令牌的概念,但凡是想要参加这个秒杀活动的用户,必须先获得这个秒杀令牌(类似于活动入场券,有了入场券才能参加活动),我们在用户进行秒杀之前先判断他有无这个令牌,有令牌的则让进来进行秒杀;并且这个令牌的数量是有限的,当我们令牌发放完毕,我们就不让其他用户在继续请求我们的后端接口,直接拒绝用户的请求,减少系统资源的消耗和压力;

我们可以设置为库存量的5倍,500w个令牌;也就是说500万用户来抢夺这个100w件商品;我们不能把令牌的数量设置=库存数量,是因为有很多用户抢到了商品,但是最后还是没有付款,所以设置的多一些,可以让其他想要买的用户去抢;

【springboot项目】之秒杀项目常见问题(Seckill)_第9张图片

还可以作为优化的地方:

1.限流操作

同时因为我们秒杀的商品种类不止一件,所以我们虽然设置了令牌机制,但是我们的秒杀流量依然很大,所以我们要进行一些限流的操作,如下图,我们在后端接口上用jmeter做后端系统的压测;比如我们这个秒杀的接口最多只能承受1w的并发,我们就要限流,比如限流8000,限流的好处就是防止系统被压垮,使得系统可以继续对外提供服务;

【springboot项目】之秒杀项目常见问题(Seckill)_第10张图片

2.队列泄洪

接口里面进行一个队列泄洪操作;

因为在我们的接口里,会有大量的线程进来,去竞争创建订单,也就是说同时竞争这个cpu资源;而Redis是单线程的(redis是单线程的,是非常快的,因为没有cpu的上下文切换和i/o的多路复用);假使我们的cpu同时只能处理100个请求,而此时已经进来10000个线程来竞争cpu,此时的话会产生很多的性能消耗;

所以我们可以考虑把这10000个线程放在一个队列里面,然后让cpu从队列里面进行消费线程,一次只拿100个,执行完以后再从队列里面取100个,这样子cpu能处理的线程数和我们提供的线程数相等,此时就不会产生一个竞争问题。

【springboot项目】之秒杀项目常见问题(Seckill)_第11张图片

3.熔断机制

利用熔断降级的逻辑保护系统,防止意外的大量的请求压垮系统,从而造成整个系统的瘫痪;

具体介绍:当出现系统无法承受的流量时候,我们利用熔断暂时先把请求全部拒绝,等到系统慢慢恢复再重新打开;

当熔断出现后,我们拒绝其他的请求,只剩下一小部分请求过来,看系统是否可以响应,等到系统恢复完全,我们再把接口全部开放;

同时配合这个降级的逻辑,也就是说,拒绝用户请求的同时返回一个友好提示:如,系统繁忙,请稍后再试

【springboot项目】之秒杀项目常见问题(Seckill)_第12张图片

4.再者我们进行分布式服务,把服务横向扩展,让更多的独立的服务器去扛这个高并发

你可能感兴趣的:(项目整理,spring,boot,后端,java,面试,rabbitmq,中间件,redis)