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

一、高并发

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. 限流&降级&熔断&隔离，