如何解决写接口出现的问题

这篇文章主要介绍“如何解决写接口出现的问题”，在日常操作中，相信很多人在如何解决写接口出现的问题问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”如何解决写接口出现的问题”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

成都创新互联公司-成都网站建设公司，专注网站制作、网站建设、网站营销推广，国际域名空间，网络空间，网站托管有关企业网站制作方案、改版、费用等问题，请联系成都创新互联公司。

深夜，领导：“你写的接口有问题!赶紧起床瞧瞧”。Ding!催命软件一响，你就知道，该 Work 了......

可思来想去，觉得不可能啊。我的代码，就是一个简单的 redis 查询啊，难不成是 Redis 挂了?

同事把证据全部发到了群里，是你的接口无疑。一个简单的 Get 查询，平均耗时达到了 2 秒。jstack，promethus  的监控，把问题全部指向到了你的接口!

登录 Redis 服务器，一切正常。该怎么办?要这么不明不白不清不楚的背个章丘大铁锅么?

快是原罪

这种情况下，要相信自己的直觉。你的接口又快又好，很可能是木秀于林，鹤立鸡群，当了替罪鸟。

在 “某些” "高并发"环境下，由于资源未做隔离，在发生问题的时候，一些日志和工具的表现，会有非常强的迷惑性。

发生问题的，都是速度最快、请求最多的接口，但理论上并不可能。

如上图。这种情况很常见。大多数请求，通过 Tomcat 线程池的调度，进行真正的业务处理。

当然线程池是不干这种脏活的，它把请求交给资源处理池去处理，比如：

• 一个数据库连接池，执行耗时的统计操作和迅速的查询操作。

• 一个 Redis 连接池，执行阻塞性的慢查询和简单的 GET SET。

• 一个 Http 连接池(HTTPClient、OkHTTP 等)，远程调用速度不等的资源。

• ...

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

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

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

一个例子

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

• 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 打印信息堆栈，或者查看一些内部的监控曲线。

可惜的是，这些信息，大部分都是骗人的，你看到的慢查询，并不是真正的慢查询。

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

但在平常的工作中，我不止一次看到有同学对此手忙脚乱。很多证据都指向了一些又快又好的接口，而这些根本和它们一点关系都没有。他们乐呵呵的截图，@相关人等，嚣张至极。

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

$ 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 的读操作上了。

在实际场景中，可以看下排行比较靠前的几个锁地址，找一下共性：

而这些显示信息非常少的堆栈，才是问题的根本原因。

如何解决

增加 Tomcat 连接池的大小，或者增加连接池的大小，并不能解决问题，大概率还会复现。

最好的解决方式，当然是把耗时的服务和正常的服务拆分开来，比如时下流行的微服务。你的服务查询慢，自己访问超时，和我的服务，一丁点儿关系都没有。

但是，你的服务即然能遇到这种问题，就证明你的公司缺乏这种改造的条件。就只能在单体服务上来做文章。

这种做法，就是隔离：

如上图，我们在同一个工程里，创建了两个 MySQL 数据库连接池，指向了相同的 MySQL 地址。

使用这种方式，连接池的操作，就能够相对做到互不影响。但到现在为止，还没完，因为你的 Tomcat 连接池依然是共享的。

慢查询相关的，从连接池中获取连接的策略，要改一下，不能一直等待，而应该采用 FailFast  的方式(获取连接短时间的超时也是可以的)，否则症状还是一样。

时下流行的熔断概念，也在一定程度上实践这种隔离性。

到此，关于“如何解决写接口出现的问题”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！