接口间断性 504 分析 (二)

上一篇说到我们换了新服务器，似乎已经解决了问题，实则不然。没过两天，504 又双叕出现了，而且还出现在新部署的服务器上。这就奇怪了，直接否定了我们之前的所有假想。

怎么办，504 仍然在继续。进行了一些分析后，发现有可能问题还是出在应用上，因为出 504 都是连续几分钟出现，而且出现的 URL 也不固定，极有可能是哪边卡住了导致的连续阻塞。这恰恰与 Netty 关系很大：

我们来看一下 Netty 的线程模型：

这里特别需要关注的是一个 EventLoop 会同时处理多个 Channel。一个 EventLoop 实际上是一个死循环跑的线程，而 Channel 实际是一个连接的抽象。那么这个 EventLoop 线程在处理多个 Channel 连接的时候，是存在一个先后顺序的，必须逐个执行。所以会存在一种情况，如果某一个 Channel 阻塞了，那么分配给这个 EventLoop 的后续待处理 Channel 也会阻塞。

那么我们的应用会不会是这个原因呢？

经过不断的加日志以及各种分析，最终得到了答案：
确实 504 就是因为某些线程卡住时间太久了，导致该线程后续待处理的请求在处理之前就已经超时了。

相关的日志，我就不截图了，太多公司的业务信息了。这里给出我的大概分析思路：

1. 日志中记录业务处理耗时、处理当前的 EventLoop 线程 ID。
2. 出现 504 后，分析第 1 条 504 对应的线程 ID，在日志中查询之后多长时间该线程才处理其它请求。
3. 利用 awk 命令搜索当天日志中处理耗时最大的那个业务是不是就在 504 出现的前面一分钟内。

经过以上分析，基本可以确定我的猜测。那究竟为什么存在一些业务会卡住呢？分析相关的日志与报错，基本是超时机制没有做好。请求阻塞的情况主要是 MySQL 卡住以及 Http 请求卡住，卡住时间都在 3 分钟以上。

修改了下超时时间，持续观察中，目前 504 已经得到了解决。

这里总结一下超时时间的配置，取经自（https://blog.csdn.net/u011191463/article/details/78664896/）：

# 3.x
HttpClient client = newHttpClient();
client.setConnectionTimeout(30000); //连接时间
client.setTimeout(30000);//数据传输时间

# 4.X
HttpClient httpClient=newDefaultHttpClient();
httpClient.getParams().setParameter(CoreConnectionPNames.CONNECTION_TIMEOUT,2000);//连接时间
httpClient.getParams().setParameter(CoreConnectionPNames.SO_TIMEOUT,2000);//数据传输时间

# 4.3
CloseableHttpClient httpClient = HttpClients.createDefault();
HttpGet httpGet=newHttpGet("http://www.baidu.com");//HTTP Get请求(POST雷同)
RequestConfig requestConfig = RequestConfig.custom().setSocketTimeout(2000).setConnectTimeout(2000).build();//设置请求和传输超时时间


​

数据库这边，由于不同的驱动设置不一样，甚至有些还不支持配置，所以我们统一在 MyBatis 这边做了配置：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE configuration PUBLIC "-//mybatis.org//DTD  Config 3.0//EN" "http://mybatis.org/dtd/mybatis-3-config.dtd">
<!-- 全局超时配置，10表示sql执行时间超过10秒时，报错 -->
<configuration>
    <settings>
        <setting name="defaultStatementTimeout" value="10" />
    </settings>
</configuration>

​

如果有些业务以上情况仍然解决不了阻塞的问题，那么可以让某些 ChannerHandler 指定 EventLoop 执行，避免阻塞 IO：

ChannelPipeline pipeline = ch.pipeline();

pipeline.addLast("decoder", new MyProtocolDecoder());

pipeline.addLast("encoder", new MyProtocolEncoder());

// Tell the pipeline to run MyBusinessLogicHandler's event handler methods
// in a different thread than an I/O thread so that the I/O thread is not blocked by
// a time-consuming task.
// If your business logic is fully asynchronous or finished very quickly, you don't
// need to specify a group.
pipeline.addLast(group, "handler", new MyBusinessLogicHandler());

​