上一篇说到我们换了新服务器,似乎已经解决了问题,实则不然。没过两天,504 又双叕出现了,而且还出现在新部署的服务器上。这就奇怪了,直接否定了我们之前的所有假想。 怎么办,504 仍然在继续。进行了一些分析后,发现有可能问题还是出在应用上,因为出 504 都是连续几分钟出现,而且出现的 URL 也不固定,极有可能是哪边 ..

接口间断性 504 分析 (二)

本贴最后更新于 240 天前,其中的信息可能已经事过景迁

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

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

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

EventLooppng

这里特别需要关注的是一个 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());

  • B3log

    B3log 是一个开源组织,名字来源于“Bulletin Board Blog”缩写,目标是将独立博客与论坛结合,形成一种新的网络社区体验,详细请看 B3log 构思。目前 B3log 已经开源了多款产品:PipeSoloSymWide 等,欢迎大家加入,贡献开源。

    1881 引用 • 3627 回帖 • 587 关注
  • Netty

    Netty 是一个基于 NIO 的客户端 - 服务器编程框架,使用 Netty 可以让你快速、简单地开发出一个可维护、高性能的网络应用,例如实现了某种协议的客户、服务端应用。

    22 引用 • 24 回帖 • 1 关注
  • MyBatis

    MyBatis 本是 Apache 软件基金会 的一个开源项目 iBatis,2010 年这个项目由 Apache 软件基金会迁移到了 google code,并且改名为 MyBatis ,2013 年 11 月再次迁移到了 GitHub。

    118 引用 • 394 回帖 • 765 关注
  • HttpClient
    6 引用 • 9 回帖
回帖   
请输入回帖内容...