【生产问题】服务假死，无法正常请求进服务

记录生产出现的问题点。

问题描述

mq的某个消费者告警了！！！

mq堆积数从5000条，不断增加到7万，一直往上升。

问题分析

查看mq集合平台查看TPS情况

登录上mq聚合平台，看目前堆积在20万，仍然在不断增加，但是TPS为0。

查看生产服务器，发现4台服务器的日志没有任何打印。重启后，刚开始10s中会打出日志，但是后面不再打印日志。

再重启其他几台服务器时，发现是同样的问题。

查看服务状态

查看启动的服务，发现正常启动。

刚启动ping一个用于测试的接口，可以正常调用通。

再过20s ping接口时，发现卡死没有返回。

查看Skywalking监控日志

查看Skywalking，发现请求某个接口时出现大量超时的情况，耗时特别长的在600s，很多耗时在200-300s。

对照代码

为什么超时时间这么久？

查看代码，发现代码中并没有设置超时时间。那么，原因就在于请求外部接口导致的了。

相当于请求外部接口时，服务一直卡在某个请求中没有中断，服务的线程数被占满。

结果就是请求进不来，一直被阻塞，最终导致服务卡死在那里。

解决办法

• 设置请求接口的超时时间；
• 将接口调用时间发送至elk，方便统计；

复盘

mq消费告警监控很重要

需要通过程序来监控服务的状态。如果单靠别人反馈出问题再查看时，就会明显滞后。

增加监控

通过排查问题点，会发现排查问题出现转折点在用sky walking查看耗时情况，然后知道了耗时超长的时间；

要加上监控工具，比如Skywalking、cat和pingpoint等监控，可以知道每个请求的耗时是多久。

增加ELK日志

方便对接口的整体耗时情况做统计。

设置接口超时时间

这点很关键，尤其是强关联的接口，一定要设置接口的请求超时时间。

否则在高并发情况下，请求一个接口耗时过长，就会使处理速度变慢，那么在消费mq数据时就可能会出现堆积的情况。

非强依赖关系，尽可能设置异步处理

在做业务处理时，可能会操作很多的数据，比如插库、请求多个外部接口等。

如果是非必要必须同步处理时，就把它异步处理，这样可以避免因某个接口挂了或者超时导致后续业务无法正常处理。

另外，异步处理，可以明显提高处理速度。