服务雪崩效应产生的背景|学习笔记

开发者学堂课程【精通 Spring Cloud Alibaba：服务隔离机制信号量与线程池隔离】学习笔记，与课程紧密联系，让用户快速学习知识

课程地址：https://developer.aliyun.com/learning/course/634/detail/10133

服务雪崩效应

默认情况下，tomcat/jetty 服务器只会有一个线程池处理所有接口的请求。

会出现一个如下问题：

这种在高并发的情况下，如果客户端所有的请求都堆积到同一个接口上，那么会产生该服务器的所有的线程都在处理该接口，可能会导致其他的接口无法访问，相当于短暂没有线程处理。

例如：

Tomcat 服务器默认情况下只有一个线程池维护我们所有线程。

假设线程池数量是为20，客户端同时发出100个请求到 userOrdertoMember 接口，另一个客户端访问 smsOrder 接口，现在线程池数量是为20，所以现在最多只有20个线程去处理请求，但是现在客户端发出了101个请求。

100个请求先访问到 userOrdertoMember 接口，至少是有81个接口在等待，而且很有可能会导致 smsOrder 接口无法访问。

因为相当于我们现在所有请求都是在处理 userOrdertoMember 接口100个请求，没有空闲去处理 smsOrder 接口，相当于别人在访问 smsOrder 接口时会转圈，

OrdertoMember 接口：

@Reques tMapping( "/orderToMemer" )

public String orderToUserMemer() {

try {

//模拟调用其他接口

Thread. sLeep( millis: 500);

} catch (Exception e) {

}

log. info(">>>" + Thread. currentThread() . getName() + "<<<");

return"订单调用会员成功";

处理会花费0.5秒再响应客户端。

smsOrder 接口：

* @return

*/

@RequestMapping( "/smsOrder")

public String smsOrder() {

log. info(">>" + Thread. current Thread(). getName() + "<<<");

return“订单发送短信消息";

}

}

先去访问到 OrdertoMember 接口（重启才能生效），再去访问smsOrder接口，都能访问。

现在比如一个黑客去攻击 OrdertoMember 接口，发出许多请求去访问OrdertoMember 接口，别人正常情况下去调用 smsOrder 接口会出现转圈情况。

因为根本没有限流去处理 smsOrder 接口

现在先创建一个线程组，把线程数设置为50，每个线程发送100个请求，总共发送50 X 100个请求，再去创建HTTP请求，服务器IP地址为127.0.04。

这样访问 smsOrder 接口，会出现转圈，比以前慢了许多。

服务雪崩效应产生原因：

tomcat 服务器只有一个线程池处理我们的接口。

如何去证明我们的 tomcat 服务器只有一个线程池处理我们所有接口的请求？

——打印线程名称  

线程名称组合：

线程池名称+线程 id 名称