CNCF中国云原生调查公布

从xjjdog上面的分析中，你应该很容易看出问题的症结所在：未隔离的瓶颈资源引起上游资源的连锁反应。

但在平常的工作中，xjjdog不止一次看到有同学对此手忙脚乱。很多证据都指向了一些又快又好的接口，而这些根本和它们一点关系都没有。

他们乐呵呵的截图，@相关人等，嚣张至极。

在遇到这种情况的时候，你可以使用下面的脚本进行初步分析：
 

如上图。这种情况很常见。

大多数请求，通过Tomcat线程池的调度，进行真正的业务处理。当然线程池是不干这种脏活的，它把请求交给资源处理池去处理，比如：

1. 一个数据库连接池，执行耗时的统计操作和迅速的查询操作
2. 一个Redis连接池，执行阻塞性的慢查询和简单的GET SET
3. 一个Http连接池(HTTPClient、OkHTTP等)，远程调用速度不等的资源

• ...

我们平常的编码中，通常都会共用这样的资源池。因为它写起代码来简单，不需要动脑。

但如果你的服务本身，并没有做好拆分以及隔离，问题就是致命的。比如，你把报表接口和高并发的C端接口放在了一个实例上。

这时候，你就有可能被报表接口给坑了。

2. 一个例子

我们以数据库连接池为例，来说明一下这个过程，先看一下以下基础信息：

• Tomcat的连接池，配置大小为200个
• MySQL的连接池，配置大小为50个，算是比较大了
• 接口A需要调用耗时的查询，耗时为5秒
• 接口B速度非常快，查询数据库响应时间在200ms以下

速度快的B接口，请求量是远远大于接口A的，平常情况下相安无事。

有一天，接口A忽然有了大量的查询，由于它的耗时比较长，迅速把数据库的50个连接池给占满了(接口B由于响应快，持有时间短，慢慢连接会被A吃掉)。

这时候，无论是接口A，还是接口B的请求，都需要等待至少5秒钟，才能获取下一条数据库连接，业务才能正常走下去。

不一小会儿，服务的状态就变成这样：

• 数据库连接池50个连接，迅速占满，而且几乎全被慢查询占满
• Tomcat连接池的200个连接，迅速被占满，其中大部分是速度快的接口B，因为它的请求量大速度快
• 所有接口都Block在Tomcat的线程上。进而造成：哪怕是查询一个非数据库的请求，也要等待5秒左右

一般在遇到这种问题的时候，我们都倾向于使用jstack打印信息堆栈，或者查看一些内部的监控曲线。可惜的是，这些信息，大部分都是骗人的，你看到的慢查询，并不是真正的慢查询。

（编辑：衡水站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!