高并发下的一些基础概念：吞吐量、QPS、并发数、响应时间，服务熔断、隔离、降级、限流，缓存穿透、缓存击穿、缓存雪崩

吞吐量、QPS、并发数、响应时间

吞吐量(Throughput)

吞吐量（TPS）：是指系统在单位时间内处理请求的数量。

• 对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。
• 对于单用户的系统，响应时间可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。
• 对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多步骤难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。

QPS（Query Per Second）

每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。 （看来是类似于TPS，只是应用于特定场景的吞吐量）

并发量

并发量（并发用户数）：是指系统可以同时承载的正常使用系统功能的用户的数量。

• 与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。

• 以网站系统为例，假设用户只有注册后才能使用，但注册用户并不是每时每刻都在使用该网站，因此具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花很多时间阅读网站上的信息，因而具体一个时刻只有部分在线用户同时向系统发出请求。

• 这样，对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。

• 由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。

响应时间(RT)

响应时间（RT）：是指系统对请求作出响应的时间。

• 直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。

• 对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。

小结

QPS和TPS的区别 ：

• TPS表示：系统在单位时间内处理请求的数量，它是软件测试结果的测量单位。
• QPS表示：对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

两个概念的针对点不一样

服务熔断、隔离、降级、限流

降级

服务降级是指：在高并发的情况下，防止用户一直等待，使用服务降级方式进行处理，直接返回一个提示给客户端（类似当前服务忙，请稍后再试），直接调用Hystrix中的fallBack方法进行降级处理。

服务降级目的：为了提高用户体验(自定义消息返回给客户端)，防止服务雪崩效应。比如：连接超时、网络延迟、服务器响应时间过长等情况。

服务雪崩效应的产生原因：因为默认情况下，只有一个线程池处理所有的服务接口，所有的请求都会被一个线程池处理，如果大量的请求访问同一个接口，当达到tomcat默认极限(可以自己设置)，可能会导致其他服务接口无法访问，我们常把基础服务故障导致的级联故障的现象称为雪崩效应。

雪崩效应描述的是提供者不可用导致消费者不可用，并将不可用逐渐扩大的过程，例如：

• A做为服务提供者(基础服务)，B为A的消费者，C和D为是B的消费者。当A不可用引起了B不可用，并将不可用像滚雪球一样放大到C和D，雪崩效应就这样形成。

熔断

服务熔断是指：当服务的访问量达到一定阈值的时候，为了保护服务，直接拒绝后续的服务（一般对后续的服务使用服务降级）。

服务熔断的目的：为了防止服务宕机(保护服务)，会进行熔断处理。

产生的原因：服务请求过多，高并发情况下，可以设置阈值进行限制，超出的请求存放在缓存队列中，如果缓存队列中线程满的话，直接拒绝访问服务，访问不了服务(熔断)。

一般熔断和降级会一起使用，对熔断的请求进行降级处理，这样显得友好一点。

隔离

服务隔离是指：每个服务接口之间互不影响。

为了解决雪崩效应：可以使用服务的隔离机制(线程池方式和信号量方式)。

服务隔离有2种实现方式：线程池方式、信号量。

• 1.线程池方式：相当于每个接口(服务)都有自己独立的线程池，不同的线程池之间互不影响，能够实现服务接口隔离。缺点：CPU内存开销较大。

• 2.信号量方式：底层使用原子计数器(atomic)，针对于每个服务都设置自己的独立的限制阈值。比如设置每个服务接口最多同时访问的次数，如果超出缓存队列请求后，自己实现拒绝策略。

默认情况下，一个项目的接口都是由一个线程池去维护的，当某个接口被大量访问的时候，其他的接口就会被迫等待，当达到线程池的极限的时候甚至会造成服务的丢失，造成服务的雪崩效应（A接口被大量访问，会造成其他接口等待，不可用）。

限流

服务限流是指：在高并发的情况，一旦服务承受不了使用服务限流机制（计数器（滑动窗口计数）、漏桶算法、令牌桶（Restlimite））

服务限流的目的：为了保护服务，避免服务宕机。

缓存穿透、缓存击穿、缓存雪崩

缓存处理流程：

• 前台请求，后台先从缓存中取数据，取到直接返回结果，取不到时从数据库中取，数据库取到更新缓存，并返回结果，数据库也没取到，那直接返回空结果。

缓存穿透

缓存穿透是指：缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1”的数据或id为特别大不存在的数据，这时的用户很可能是攻击者，攻击会导致数据库压力过大。

解决方案：

• 接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
• 从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用），这样可以防止攻击用户反复用同一个id暴力攻击

缓存击穿

缓存击穿是指：缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力

解决方案：

• 设置热点数据永远不过期。
• 当缓存中没有数据，需要去数据库中查的时候，第一个获得执行权的线程对这个请求加锁（互斥锁），查询到数据之后将其放入缓存中，然后其他线程去并发访问缓存中的数据，这样可以防止都去数据库中读取数据，导致数据库压力过大。

缓存雪崩

缓存雪崩是指：缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。

和缓存击穿不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。

解决方案：

• 缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
• 如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。
• 设置热点数据永远不过期。

参考链接：
https://www.cnblogs.com/ming-blogs/p/10793694.html
https://www.cnblogs.com/ming-blogs/p/10793694.html