并发

问：什么是并发？

并发指的是并发访问，也就是在某个时间点，有多少个访问请求同时到来。并发处理能力主要看服务器配置，服务器配置越高，在单位时间里处理的请求就越多。

问：衡量一个服务器处理并发能力的指标有哪些？

1️⃣QPS（每秒查询率）：每秒请求数量。

2️⃣吞吐量：单位时间内处理请求的数量。

3️⃣响应时间：系统对请求做出响应的时间。

4️⃣并发用户数：能够承载正常使用系统的用户数量。

问：如何提高服务器的并发处理能力？

两种方式，第一种提高单机硬件的性能，第二种采用分布式开发架构，增加机器数量。

前者被称为“垂直扩展”，后者被称为“水平扩展”，提升硬件性能是有极限的，终极解决方法主要还是靠后者水平扩展。
问：并发和多线程之间是什么关系？

实现高并发是目的，采用多线程一种实现手段。并发是指服务器同时处理多个请求的能力，而处理并发最好的方式就是采用多线程。
问：高并发和多线程的应用场景有哪些？

多线程应用场景：

1️⃣连续操作（多用户请求）

2️⃣并行计算（执行慢而不影响主程序的程序块）

3️⃣等待网络、文件系统、用户或其他I/O响应（切片上传、Scoket）

高并发应用场景：

访问量过大导致的服务器处理不过来（电商秒杀活动、12306抢票）

问：如何处理高并发？

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️⃣限流&降级&熔断&隔离。

附：

大规模并发的场景

超发：假设秒杀场景中，商品有100个，最后一刻已经抢购了99个还剩下1个，这个时候，客户大批量请求过来，造成系统多个并发请求，这批请求读取到的余量都是1，然后都通过了这一余量判断，导致超发（抢购量>实际拥有量）。

解决思路：

1️⃣悲观锁思路，修改数据的时候先锁定，等这个线程处理完数据其他线程再去操作数据，但是高并发情况下，会有很多请求，这样一个一个处理极其费时，连接数被耗尽导致系统异常，有些线程甚至永远也不可能抢到锁，这种请求也会死在那里。——不可行

2️⃣FIFO队列思路（FIFO:先进先出）我们把大批量请求放在队列中，采用FIFO，让请求先进先出，这样就不会导致某些请求永远获取不到锁。虽然解决了锁的问题，但是有个新的问题——高并发下因为请求很多可能一瞬间将内存“撑爆”，然后系统又陷入异常；其次队列处理速度跟不上WEB请求涌入的速度，导致队列内请求越来越对，系统瘫痪。——不可行

3️⃣乐观锁思路，乐观锁就是带着版本号去请求，只有内存中的版本号和请求的版本号一致才能抢购成功，其他线程都会返回抢购失败。这样就不用考虑队列的问题，不过乐观锁的缺点是增大了CPU开销，综合来说这是一个比较好的解决方案。——可行