实际项目中如何应对高并发等场景

一、高并发

1. 高并发(High Concurrency)是互联网分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计保证系统能够同时并行处理很多请求。

高并发相关常用的一些指标有响应时间(Response Time),吞吐量(Throughput),每秒查询率QPS(Query Per Second),并发用户数等。

响应时间:系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms,这个200ms就是系统的响应时间。

吞吐量:单位时间内处理的请求数量。

QPS:每秒响应请求数。在互联网领域,这个指标和吞吐量区分的没有这么明显。

并发用户数:同时承载正常使用系统功能的用户数量。例如一个即时通讯系统,同时在线量一定程度上代表了系统的并发用户数。

2.如何处理应对高并发场景?

1.前端处理

1. 采用前后端分离的模式,前端项目单独部署到服务器上面

2. 前端对请求接口进行置灰操作,等到这个时间点再开启点击

3. 前端加入CDN 加速服务

4. 前端引入Nginx,如果不够,加入集群Nginx,还不行,直接上LVS

5. 前端对访问的URL 进行特殊处理,MD5加密请求后台,或加入特殊的字符去请求后台,后台识别到进行访问,否则直接返回null

6. 前端限流:这个很简单,一般秒杀不会让你一直点的,一般都是点击一下或者两下然后几秒之后才可以继续点击,这也是保护服务器的一种手段

2.后端处理

1. 服务单一原则,秒杀就是秒杀服务,商品就是商品服务,一个服务挂了,不至于把其他服务搞崩溃

2. Redis做集群,读多写少,Redis集群主从同步读写分离 还搞点哨兵,开启持久化直接无敌高可用!

3. Nginx大家想必都不陌生了吧,这玩意是高性能的web服务器,并发也随便顶几万不是梦,但是我们的Tomcat只能顶几百的并发呀,那简单呀负载均衡嘛,一台服务几百,那就多搞点,在秒杀的时候多租点流量机

4. 秒杀的时候肯定是涉及到后续的订单生成和支付等操作,但是都只是成功的幸运儿才会走到那一步,那一旦100个产品卖光了,return了一个false,前端直接秒杀结束,然后你后端也关闭后续无效请求的介入了。

5. 库存预热, 秒杀前你通过定时任务或者运维同学提前把商品的库存加载到Redis中去,让整个流程都在Redis里面去做,然后等秒杀介绍了,再异步的去修改库存就好了。

6.削峰填谷MQ你可以把它放消息队列,然后一点点消费去改库存就好了嘛,不过单个商品其实一次修改就够了,我这里说的是某个点多个商品一起秒杀的场景

7. 加入分布式锁,多个请求来的时候,可以防止超卖问题

8. 限流&降级&熔断&隔离,

原文入口

一个小小后端的爬行痕迹
原文地址:https://www.cnblogs.com/heikedeblack/p/14373658.html