如何在祖传代码快速拔出骨刺,造就流畅的API

/ 0评 / 0

起因

刚从前几天的修改配置导致服务假死中缓过劲来,我还在享受着周日の甜蜜美梦。突然服务监控传来噩耗,说是我们订单服务宕机了。哦豁,一看时间早上八点零五。不过这些事情我当时并不是知道,因为那天手机关机了(这不是重点),后来在下午分析了一下问题出现的原因。我们又遇到了缓存穿透。这让我想起了Q1那噩梦的一天,还好这次只是单个服务宕机,冷静下来我们开始追溯事情发生的原因。
订单服务只是部署在两台机器(我们的量你懂的。没啥请求),其负责的内容则是查询订单信息和下单等业务,早上八点的宕机运维告诉我们是由于一条慢SQL重复执行多次,导致占满了链接池链接,继而其他的API要执行查询操作时拿不到DB的链接,最终恶性循环,服务的连接数达到了上线,最终处于假死状态,新来的请求不再有返回结果,服务处于不可用状态。(真就得了慢SQL,一个传染两)
而造成这个慢sql堆积的原因则是APP首页的缓存失效了,导致请求查询不到缓存,继而缓存穿透最终直接通过内部请求查询DB。加之SQL本身也存在问题,没有合理的索引和大表之间的Join导致执行时间几乎在分钟级别。
我们只是紧急的上了慢SQL的缓存,加大了缓存失效的时间,做完这一系列操作之后我们意识到不能再让服务裸奔了,得有完善的监控和对错误的良好FeedBack。的确,目前缺少SQL级别的服务监控。

解决方式

Druid监控

想要解决慢SQL得先知道哪些SQL慢,所以第一步得先增加对链接的监控
项目加入Duridweb的依赖:

在DataSource的配置中开启DruidMonitor:

这样服务启动之后druid监控也随之启动,这里有更多详细关于数据源的配置就不描述了。访问服务Ip+port/druid/index.html 可以看到有哪些sql慢。但是作为一个提供API服务的应用,我们更在乎uri的响应和uri对应方法执行SQL的快慢,当在一个事务中执行的时候,随着扫描行数的走高,最终形成慢API,而这些接口可能是达到某些条件之后才会扫描那么多行。但是人工查询很吃对接口的了解程度,有些接口业务逻辑复杂,容易出现一些晦涩难懂的桥段,但是我们只是优化SQL速度的,并不关心业务流程(针对查询),所以我们需要一个工具来帮助我们分析和修改。

Arthas

这里使用到一款阿里的Java诊断工具,Github:arthas,而SQL是执行慢,所以我们主要使用 trace 命令来寻找低速的代码段,有关trace的详细介绍:https://alibaba.github.io/arthas/trace.html
在服务器wget一下子,启动已java -jar的方式启动,他会自动扫描在这台服务器上运行的java应用,然后ps -ef 找到自己的java应用的pid 然后选择进入。
然后就可以使用trace命令来查看到底是哪块的代码执行缓慢进而修改程序来优化。

最后

修改慢SQL是一件非常费劲的事情,在修改之前得理解之前的业务逻辑,在参数相同的情况使用不同的查询方式产生相同的结果,或者是合理建立索引(当然缓慢的SQL大部分情况下都是不走索引导致扫描全表而带来的缓慢),亦或者从流程上逐渐缩小查询的集合大小。修改需要时间,健壮的服务离不开合理的、符合设计规范的程序和DB。

发表评论

电子邮件地址不会被公开。 必填项已用*标注