温馨提示：如果你没有相关的从业经验，本文将会非常晦涩。
深夜，领导： “你写的接口有问题！赶紧起床瞧瞧”。
Ding！催命软件一响，你就知道，该work了。
可思来想去，觉得不可能啊。我的代码，就是一个简单的redis查询啊，难不成是Redis挂了？
同事把证据全部发到了群里，是你的接口无疑。一个简单的Get查询，平均耗时达到了2秒。jstack，promethus的监控，把问题全部指向到了你的接口！
登录Redis服务器，一切正常。该怎么办？要这么不明不白不清不楚的背个章丘大铁锅么？
1. 快是原罪
这种情况下，要相信自己的直觉。你的接口又快又好，很可能是木秀于林，鹤立鸡群，当了替罪鸟。
在 “某些” "高并发"环境下，由于资源未做隔离，在发生问题的时候，一些日志和工具的表现，会有非常强的迷惑性。
发生问题的，都是速度最快、请求最多的接口，但理论上并不可能。
如上图。这种情况很常见。
大多数请求，通过Tomcat线程池的调度，进行真正的业务处理。当然线程池是不干这种脏活的，它把请求交给资源处理池去处理，比如：
- 一个数据库连接池，执行
耗时的统计操作和迅速的查询操作 - 一个Redis连接池，执行
阻塞性的慢查询和简单的GET SET - 一个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打印信息堆栈，或者查看一些内部的监控曲线。可惜的是，这些信息，大部分都是骗人的，你看到的慢查询，并不是真正的慢查询。
从xjjdog上面的分析中，你应该很容易看出问题的症结所在：未隔离的瓶颈资源引起上游资源的连锁反应。
但在平常的工作中，xjjdog不止一次看到有同学对此手忙脚乱。很多证据都指向了一些又快又好的接口，而这些根本和它们一点关系都没有。
他们乐呵呵的截图，@相关人等，嚣张至极。
在遇到这种情况的时候，你可以使用下面的脚本进行初步分析：
$ cat 10271.tdump| grep "waiting to lock " | awk '{print $5}' | sort | uniq -c | sort -k1 -r
26 <0x0000000782e1b590>
18 <0x0000000787b00448>
16 <0x0000000787b38128>
10 <0x0000000787b14558>
复制代码上面的例子，我们找到给0x0000000782e1b590上锁的执行栈，可以发现全部是卡在HttpClient的读操作上了。在实际场景中，可以看下排行比较靠前的几个锁地址，找一下共性。
而这些显示信息非常少的堆栈，才是问题的根本原因。
3. 如何解决
增加Tomcat连接池的大小，或者增加连接池的大小，并不能解决问题，大概率还会复现。
最好的解决方式，当然是把耗时的服务和正常的服务拆分开来，比如时下流行的微服务。你的服务查询慢，自己访问超时，和我的服务，一丁点儿关系都没有。
但是，你的服务即然能遇到这种问题，就证明你的公司缺乏这种改造的条件。就只能在单体服务上来做文章。
这种做法，就是隔离。
如上图，我们在同一个工程里，创建了两个MySQL数据库连接池，指向了相同的MySQL地址。使用这种方式，连接池的操作，就能够相对做到互不影响。
但到现在为止，还没完，因为你的Tomcat连接池依然是共享的。
慢查询相关的，从连接池中获取连接的策略，要改一下，不能一直等待，而应该采用FailFast的方式（获取连接短时间的超时也是可以的），否则症状还是一样。
时下流行的熔断概念，也在一定程度上实践这种隔离性。
End
我们还可以联想到类似的场景：
JVM发生STW，停顿期间，受影响最大的，就是那些又快请求又大的接口。而那些耗时接口，由于平常就是那个鸟样，倒没人关注它的异常情况。
一堆接口连接了同一个数据库，当数据库发生抖动，受影响最大的，依然是那些又快请求又大的接口。因为那些耗时的慢查询，一直就是那样表现的，没人会怀疑到它们身上来。
殊不知，只要这些烂接口请求量一上升，就会像一颗老鼠屎，坏了整锅汤，所有的请求都会被拖累。
这有点类似于我们平常的工作：低效的人一增多，就会拖累整个项目的进度。领导一直在纳闷，为什么那么多技术好手，效率那么低呢？
这是因为，他们被拖累了。过于关注个体，最根本性的问题却掩盖在表象之下。
公司内部的研发，从来不应该一视同仁。不同技术追求的员工，也应该做到类似的隔离，宁缺毋滥。
好手组成的团队，交流顺畅，目标一致，效率奇高；而那些擅长拖慢项目的员工，就应该放在低效的团队，将加班进行到底。
说了这么多，问题的关键就在于：并不是每一个人都能了解这个规律，很少有人会关注这背后的根本原因。你要给领导解释你的接口没有问题，需要花费很大的力气。
“老板，我找到原因了。是因为一个MySQL慢查询，把Tomcat的连接池占满了，造成了Redis对应的Http请求响应慢。”这样错综复杂的关系，真的让人很头痛。
“很好”，领导说，“这个问题，就有你牵头来解决一下吧”。
你瞧，做领导的，大多不会关注问题产生的原因，他只关注谁能解决这个问题，哪怕不是你的问题。谁让你代码写得好，需求又做的快呢！
作者：小姐姐味道
链接：https://juejin.cn/post/6901541220661936136