高併發場景下的httpClient優化使用

時間 2019-11-11

標籤併發場景 httpclient 優化使用欄目系統網絡简体版

原文原文鏈接

1.背景java

咱們有個業務，會調用其餘部門提供的一個基於http的服務，日調用量在千萬級別。使用了httpclient來完成業務。以前由於qps上不去，就看了一下業務代碼，並作了一些優化，記錄在這裏。nginx

先對比先後：優化以前，平均執行時間是250ms；優化以後，平均執行時間是80ms，下降了三分之二的消耗，容器再也不動不動就報警線程耗盡了，清爽~程序員

2.分析數據庫

項目的原實現比較粗略，就是每次請求時初始化一個httpclient，生成一個httpPost對象，執行，而後從返回結果取出entity，保存成一個字符串，最後顯式關閉response和client。咱們一點點分析和優化：緩存

2.1 httpclient反覆建立開銷安全

httpclient是一個線程安全的類，沒有必要由每一個線程在每次使用時建立，全局保留一個便可。服務器

2.2 反覆建立tcp鏈接的開銷併發

tcp的三次握手與四次揮手兩大裹腳布過程，對於高頻次的請求來講，消耗實在太大。試想若是每次請求咱們須要花費5ms用於協商過程，那麼對於qps爲100的單系統，1秒鐘咱們就要花500ms用於握手和揮手。又不是高級領導，咱們程序員就不要搞這麼大作派了，改爲keep alive方式以實現鏈接複用！socket

2.3 重複緩存entity的開銷tcp

本來的邏輯裏，使用了以下代碼：

HttpEntity entity = httpResponse.getEntity();
String response = EntityUtils.toString(entity);
這裏咱們至關於額外複製了一份content到一個字符串裏，而本來的httpResponse仍然保留了一份content，須要被consume掉，在高併發且content很是大的狀況下，會消耗大量內存。而且，咱們須要顯式的關閉鏈接，ugly。

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左右，效果顯著。 --------------------- 做者：aa1215018028 來源：CSDN 原文：https://blog.csdn.net/aa1215018028/article/details/81158464?utm_source=copy 版權聲明：本文爲博主原創文章，轉載請附上博文連接！