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的開銷
原本的邏輯裡，使用瞭如下代碼：
<code>HttpEntity entity = httpResponse.getEntity();String response = EntityUtils.toString(entity);/<code>
這裡我們相當於額外複製了一份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如下：
<code>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 }};/<code>3.2 配置一個PoolingHttpClientConnectionManager
<code>PoolingHttpClientConnectionManager connectionManager = new PoolingHttpClientConnectionManager();connectionManager.setMaxTotal(500);connectionManager.setDefaultMaxPerRoute(50);//例如默認每路由最高50併發，具體依據業務來定/<code>
也可以針對每個路由設置併發數。
3.3 生成httpclient
<code>httpClient = HttpClients.custom() .setConnectionManager(connectionManager) .setKeepAliveStrategy(kaStrategy) .setDefaultRequestConfig(RequestConfig.custom().setStaleConnectionCheckEnabled(true).build()) .build();/<code>
注意：使用setStaleConnectionCheckEnabled方法來逐出已被關閉的鏈接不被推薦。更好的方式是手動啟用一個線程，定時運行closeExpiredConnections 和closeIdleConnections方法，如下所示。
<code>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(); } } }/<code>3.4 使用httpclient執行method時降低開銷
這裡要注意的是，不要關閉connection。
一種可行的獲取內容的方式類似於，把entity裡的東西複製一份：
<code>res = EntityUtils.toString(response.getEntity(),"UTF-8");EntityUtils.consume(response1.getEntity());/<code>
但是，更推薦的方式是定義一個ResponseHandler，方便你我他，不再自己catch異常和關閉流。在此我們可以看一下相關的源碼：
<code>publicT 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; } /<code>
可以看到，如果我們使用resultHandler執行execute方法，會最終自動調用consume方法，而這個consume方法如下所示：
<code>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(); } } }/<code>可以看到最終它關閉了輸入流。
4.其他
通過以上步驟，基本就完成了一個支持高併發的httpclient的寫法，下面是一些額外的配置和提醒：
4.1 httpclient的一些超時配置
CONNECTION_TIMEOUT是連接超時時間，SO_TIMEOUT是socket超時時間，這兩者是不同的。連接超時時間是發起請求前的等待時間；socket超時時間是等待數據的超時時間。
<code>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));/<code>
4.2 如果配置了nginx的話，nginx也要設置面向兩端的keep-alive
現在的業務裡，沒有nginx的情況反而比較稀少。nginx默認和client端打開長連接而和server端使用短鏈接。注意client端的keepalive_timeout和keepalive_requests參數，以及upstream端的keepalive參數設置，這三個參數的意義在此也不再贅述。
以上就是我的全部設置。通過這些設置，成功地將原本每次請求250ms的耗時降低到了80左右，效果顯著。
原文地址：https://www.cnblogs.com/bethunebtj/p/8493379.html
閱讀更多 架構師筆記 的文章
