高并发场景下的httpClient优化使用

155次阅读

没有评论

共计 5972 个字符，预计需要花费 15 分钟才能阅读完成。

1. 背景

我们有个业务，会调用其他部门提供的一个基于 http 的服务，日调用量在千万级别。使用了 httpclient 来完成业务。之前因为 qps 上不去，就看了一下业务代码，并做了一些优化，记录在这里。

先对比前后：优化之前，平均执行时间是 250ms；优化之后，平均执行时间是 80ms，降低了三分之二的消耗，容器不再动不动就报警线程耗尽了，清爽~

2. 分析

项目的原实现比较粗略，就是每次请求时初始化一个 httpclient，生成一个 httpPost 对象，执行，然后从返回结果取出 entity，保存成一个字符串，最后显式关闭 response 和 client。我们一点点分析和优化：

2.1 httpclient 反复创建开销

httpclient 是一个线程安全的类，没有必要由每个线程在每次使用时创建，全局保留一个即可。

2.2 反复创建 tcp 连接的开销

tcp 的三次握手与四次挥手两大裹脚布过程，对于高频次的请求来说，消耗实在太大。试想如果每次请求我们需要花费 5ms 用于协商过程，那么对于 qps 为 100 的单系统，1 秒钟我们就要花 500ms 用于握手和挥手。又不是高级领导，我们程序员就不要搞这么大做派了，改成 keep alive 方式以实现连接复用！

2.3 重复缓存 entity 的开销

原本的逻辑里，使用了如下代码：

HttpEntity entity = httpResponse.getEntity();
String response = EntityUtils.toString(entity);

这里我们相当于额外复制了一份 content 到一个字符串里，而原本的 httpResponse 仍然保留了一份 content，需要被 consume 掉，在高并发且 content 非常大的情况下，会消耗大量内存。

3. 实现

按上面的分析，我们主要要做三件事：一是单例的 client，二是缓存的保活连接，三是更好的处理返回结果。一就不说了，来说说二。

提到连接缓存，很容易联想到数据库连接池。httpclient4 提供了一个 PoolingHttpClientConnectionManager 作为连接池。接下来我们通过以下步骤来优化：

3.1 定义一个 keep alive strategy

关于 keep-alive，本文不展开说明，只提一点，是否使用 keep-alive 要根据业务情况来定，它并不是灵丹妙药。还有一点，keep-alive 和 time_wait/close_wait 之间也有不少故事。

在本业务场景里，我们相当于有少数固定客户端，长时间极高频次的访问服务器，启用 keep-alive 非常合适

再多提一嘴，http 的 keep-alive 和 tcp 的 KEEPALIVE 不是一个东西。回到正文，定义一个 strategy 如下：

ConnectionKeepAliveStrategy myStrategy = new ConnectionKeepAliveStrategy() {
@Override
public long getKeepAliveDuration(HttpResponse response, HttpContext context) {
HeaderElementIterator it = new BasicHeaderElementIterator
(response.headerIterator(HTTP.CONN_KEEP_ALIVE));
while (it.hasNext()) {
HeaderElement he = it.nextElement();
String param = he.getName();
String value = he.getValue();
if (value != null && param.equalsIgnoreCase
(“timeout”)) {
return Long.parseLong(value) * 1000;
}
}
return 60 * 1000;// 如果没有约定，则默认定义时长为 60s
}
};

3.2 配置一个 PoolingHttpClientConnectionManager

PoolingHttpClientConnectionManager connectionManager = new PoolingHttpClientConnectionManager();
connectionManager.setMaxTotal(500);
connectionManager.setDefaultMaxPerRoute(50);// 例如默认每路由最高 50 并发，具体依据业务来定

也可以针对每个路由设置并发数。

3.3 生成 httpclient

httpClient = HttpClients.custom()
.setConnectionManager(connectionManager)
.setKeepAliveStrategy(kaStrategy)
.setDefaultRequestConfig(RequestConfig.custom().setStaleConnectionCheckEnabled(true).build())
.build();

注意：使用 setStaleConnectionCheckEnabled 方法来逐出已被关闭的链接不被推荐。更好的方式是手动启用一个线程，定时运行 closeExpiredConnections 和 closeIdleConnections 方法，如下所示。

public static class IdleConnectionMonitorThread extends Thread {

private final HttpClientConnectionManager connMgr;
private volatile boolean shutdown;

public IdleConnectionMonitorThread(HttpClientConnectionManager connMgr) {
super();
this.connMgr = connMgr;
}

@Override
public void run() {
try {
while (!shutdown) {
synchronized (this) {
wait(5000);
// Close expired connections
connMgr.closeExpiredConnections();
// Optionally, close connections
// that have been idle longer than 30 sec
connMgr.closeIdleConnections(30, TimeUnit.SECONDS);
}
}
} catch (InterruptedException ex) {
// terminate
}
}

public void shutdown() {
shutdown = true;
synchronized (this) {
notifyAll();
}
}

}

3.4 使用 httpclient 执行 method 时降低开销

这里要注意的是，不要关闭 connection。

一种可行的获取内容的方式类似于，把 entity 里的东西复制一份：

res = EntityUtils.toString(response.getEntity(),”UTF-8″);
EntityUtils.consume(response1.getEntity());

但是，更推荐的方式是定义一个 ResponseHandler，方便你我他，不再自己 catch 异常和关闭流。在此我们可以看一下相关的源码：

public <T> T execute(final HttpHost target, final HttpRequest request,
final ResponseHandler<? extends T> responseHandler, final HttpContext context)
throws IOException, ClientProtocolException {
Args.notNull(responseHandler, “Response handler”);

final HttpResponse response = execute(target, request, context);

final T result;
try {
result = responseHandler.handleResponse(response);
} catch (final Exception t) {
final HttpEntity entity = response.getEntity();
try {
EntityUtils.consume(entity);
} catch (final Exception t2) {
// Log this exception. The original exception is more
// important and will be thrown to the caller.
this.log.warn(“Error consuming content after an exception.”, t2);
}
if (t instanceof RuntimeException) {
throw (RuntimeException) t;
}
if (t instanceof IOException) {
throw (IOException) t;
}
throw new UndeclaredThrowableException(t);
}

// Handling the response was successful. Ensure that the content has
// been fully consumed.
final HttpEntity entity = response.getEntity();
EntityUtils.consume(entity);// 看这里看这里
return result;
}

可以看到，如果我们使用 resultHandler 执行 execute 方法，会最终自动调用 consume 方法，而这个 consume 方法如下所示：

public static void consume(final HttpEntity entity) throws IOException {
if (entity == null) {
return;
}
if (entity.isStreaming()) {
final InputStream instream = entity.getContent();
if (instream != null) {
instream.close();
}
}
}

可以看到最终它关闭了输入流。

4. 其他

通过以上步骤，基本就完成了一个支持高并发的 httpclient 的写法，下面是一些额外的配置和提醒：

4.1 httpclient 的一些超时配置

CONNECTION_TIMEOUT 是连接超时时间，SO_TIMEOUT 是 socket 超时时间，这两者是不同的。连接超时时间是发起请求前的等待时间；socket 超时时间是等待数据的超时时间。

HttpParams params = new BasicHttpParams();
// 设置连接超时时间
Integer CONNECTION_TIMEOUT = 2 * 1000; // 设置请求超时 2 秒钟根据业务调整
Integer SO_TIMEOUT = 2 * 1000; // 设置等待数据超时时间 2 秒钟根据业务调整

// 定义了当从 ClientConnectionManager 中检索 ManagedClientConnection 实例时使用的毫秒级的超时时间
// 这个参数期望得到一个 java.lang.Long 类型的值。如果这个参数没有被设置，默认等于 CONNECTION_TIMEOUT，因此一定要设置。
Long CONN_MANAGER_TIMEOUT = 500L; // 在 httpclient4.2.3 中我记得它被改成了一个对象导致直接用 long 会报错，后来又改回来了

params.setIntParameter(CoreConnectionPNames.CONNECTION_TIMEOUT, CONNECTION_TIMEOUT);
params.setIntParameter(CoreConnectionPNames.SO_TIMEOUT, SO_TIMEOUT);
params.setLongParameter(ClientPNames.CONN_MANAGER_TIMEOUT, CONN_MANAGER_TIMEOUT);
// 在提交请求之前测试连接是否可用
params.setBooleanParameter(CoreConnectionPNames.STALE_CONNECTION_CHECK, true);

// 另外设置 http client 的重试次数，默认是 3 次；当前是禁用掉（如果项目量不到，这个默认即可）
httpClient.setHttpRequestRetryHandler(new DefaultHttpRequestRetryHandler(0, false));

4.2 如果配置了 nginx 的话，nginx 也要设置面向两端的 keep-alive

现在的业务里，没有 nginx 的情况反而比较稀少。nginx 默认和 client 端打开长连接而和 server 端使用短链接。注意 client 端的 keepalive_timeout 和 keepalive_requests 参数，以及 upstream 端的 keepalive 参数设置，这三个参数的意义在此也不再赘述。

以上就是我的全部设置。通过这些设置，成功地将原本每次请求 250ms 的耗时降低到了 80 左右，效果显著。

正文完

星哥说事-微信公众号