在實際開發過程中，筆者見過太多故障是因為超時沒有設置或者設置的不對而造成的。而這些故障都是因為沒有意識到超時設置的重要性而造成的。如果應用不設置超時，則可能會導致請求響應慢，慢請求累積導致連鎖反應，甚至應用雪崩。而有些中間件或者框架在超時后會進行重試(如設置超時重試兩次)，讀服務天然適合重試，但寫服務大多不能重試(如寫訂單，如果寫服務是冪等，則重試是允許的)，重試次數太多會導致多倍請求流量，即模擬了DDoS攻擊，后果可能是災難，因此，務必設置合理的重試機制，并且應該和熔斷、快速失敗機制配合。在進行代碼Review時，一定記得Review超時與重試機制。

本文主要從Web應用/服務化應用的角度出發介紹如何設置超時與重試(系統層面的超時設置本文沒有涉及)，而Web應用需要在如下鏈條中設置超時與重試機制。

從上圖來看，在整個鏈條中的每一個點都要考慮設置超時與重試機制。而其中最重要的超時設置是網絡連接/讀/寫的超時時間設置。

本文將按照如下分類進行超時與重試機制的講解。

• 代理層超時與重試：如Haproxy、Nginx、Twemproxy，這些組件實現代理功能，如Haproxy和Nginx可以實現請求的負載均衡。而Twemproxy可以實現Redis的分片代理。需要設置代理與后端真實服務器之間的網絡連接/讀/寫超時時間。

• Web容器超時：如Tomcat、Jetty等，提供HTTP服務運行環境的。需要設置客戶端與容器之間的網絡連接/讀/寫超時時間，和在此容器中默認Socket網絡連接/讀/寫超時時間。

• 中間件客戶端超時與重試：如JSF(京東SOA框架)、Dubbo、JMQ(京東消息中間件)、CXF、Httpclient等，需要設置客戶的網絡連接/讀/寫超時時間與失敗重試機制。

• 數據庫客戶端超時：如Mysql、Oracle，需要分別設置JDBC Connection、Statement的網絡連接/讀/寫超時時間。事務超時時間，獲取連接池連接等待時間。

• NoSQL客戶端超時：如Mongo、Redis，需要設置其網絡連接/讀/寫超時時間，獲取連接池連接等待時間。

• 業務超時：如訂單取消任務、超時活動關閉。還有如通過Future#get(timeout,unit)限制某個接口的超時時間。

• 前端Ajax超時：瀏覽器通過Ajax訪問時的網絡連接/讀/寫超時時間。

從如上分類可以看出，其中最重要的超時設置是網絡相關的超時設置。

一、代理層超時與重試

對于代理層我們以Nginx和Twemproxy案例來講解。首先，看下Nginx的相關超時設置。

1. Nginx

Nginx主要有四類超時設置：客戶端超時設置、DNS解析超時設置、代理超時設置，如果使用ngx_lua，則還有lua相關的超時設置。

(1) 客戶端超時設置

對于客戶端超時主要設置有讀取請求頭超時時間、讀取請求體超時時間、發送響應超時時間、長連接超時時間。通過客戶端超時設置避免客戶端惡意或者網絡狀況不佳造成連接長期占用，影響服務端的可處理的能力。

• client_header_timeout time：設置讀取客戶端請求頭超時時間，默認為60s，如果在此超時時間內客戶端沒有發送完請求頭，則響應408(RequestTime-out)狀態碼給客戶端。
• client_body_timeout time：設置讀取客戶端內容體超時時間，默認為60s，此超時時間指的是兩次成功讀操作間隔時間，而不是發送整個請求體的超時時間，如果在此超時時間內客戶端沒有發送任何請求體，則響應408(RequestTime-out)狀態碼給客戶端。
• send_timeout time：設置發送響應到客戶端的超時時間，默認為60s，此超時時間指的也是兩次成功寫操作間隔時間，而不是發送整個響應的超時時間。如果在此超時時間內客戶端沒有接收任何響應，則Nginx關閉此連接。
• keepalive_timeout timeout [header_timeout]：設置HTTP長連接超時時間，其中，第一個參數timeout是告訴Nginx長連接超時時間是多少，默認為75s。第二個參數header_timeout是用于設置響應頭“Keep-Alive: timeout=time”，即告知客戶端長連接超時時間。兩個參數可以不一樣，“Keep-Alive:timeout=time”響應頭可以在Mozilla和Konqueror系列瀏覽器起作用，而MSIE長連接默認大約為60s，而不會使用“Keep-Alive: timeout=time”。如Httpclient框架會使用“Keep-Alive: timeout=time”響應頭的超時(如果不設置默認，則認為是永久)。如果timeout設置為0，則表示禁用長連接。

此參數要配合keepalive_disable 和keepalive_requests一起使用。keepalive_disable 表示禁用哪些瀏覽器的長連接，默認值為msie6，即禁用一些老版本的MSIE的長連接支持。keepalive_requests參數作用是一個客戶端可以通過此長連接的請求次數，默認為100。

首先，瀏覽器在請求時會通過如下請求頭告知服務器是否支持長連接。

http/1.0默認是關閉長連接的，需要添加HTTP請求頭“Connection:Keep-Alive”才能啟用。而http/1.1默認啟用長連接，需要添加HTTP請求頭“Connection: close”才關閉。

接著，如果Nginx設置keepalive_timeout 5s，則瀏覽器會收到如下響應頭。

下圖是wireshark抓包，可以看到后兩次請求沒有三次握手。

如果Nginx設置keepalive_timeout 10s 10s，則瀏覽器會收到如下響應頭。

服務器端會在10s后發送FIN主動關閉連接。

如果Nginx設置keepalive_timeout為75s 30s。

如下是Chrome瀏覽器的Wireshark抓包，在45秒時，Chrome發送了TCPKeep-Alive來保活TCP連接，在第57秒時，瀏覽器又發出了一次請求。而132秒時，Nginx發出了FIN來關閉連接(75秒連接沒活躍了)。

如下是IE瀏覽器抓包數據，在請求后第65秒左右時，瀏覽器重置了連接。

可以看出不同瀏覽器超時處理方式不一樣，而HTTP響應頭“Keep-Alive: timeout=30”對Chrome和IE都沒有起作用。

接著，如果keepalive_timeout 0，則瀏覽器會收到如下響應頭。

對于客戶端超時設置，要根據實際場景來決定，如果是短連接服務，則可以考慮設置的短一些，如果是文件上傳，則需要考慮設置的時間長一些。另外，筆者見過很多人長連接并沒有配置正確，建議配置完成后通過抓包查看長連接是否起作用了。keepalive_timeout和keepalive_requests是控制長連接的兩個維度，只要其中一個到達設置的閾值連接就會被關閉。

(2) DNS解析超時設置

resolver_timeout 30s：設置DNS解析超時時間，默認為30s。其配合resolver address ... [valid=time]進行DNS域名解析。當在Nginx中使用域名時，就需要考慮設置這兩個參數。在社區版Nginx中采用如下配置。

upstream backend { 
    server c0.3.cn; 
    server c1.3.cn; 
} 

如上兩個域名會在Nginx解析配置文件的階段被解析成IP地址并記錄到upstream上，當這兩個域名對應的IP地址發生變化時，該upstream不會更新。Nginx商業版是支持動態更新的。

一種簡單辦法是使用如下方式，每次都會動態解析域名，這種情況在多域名情況下比較麻煩，實現就不優雅了。

location /test { 
   proxy_pass http://c0.3.cn; 
} 

如果使用Openresty，則可以通過Lua庫lua-resty-dns進行DNS解析。

localresolver = require "resty.dns.resolver" 
  local r, err = resolver:new{ 
      nameservers = {"8.8.8.8",{"8.8.4.4", 53} }, 
      retrans = 5,  -- 5 retransmissions on receive timeout 
      timeout = 2000,  -- 2 sec 
  } 

當使用Nginx 1.5.8、1.7.4及遇到

could not be resolved(110:Operation timed out)； 

或者

wrong ident 37278 response for ***.jd.local, expected 33517 
unexpected response for ***.jd.local 

可能是遇到了如下BUG(http://nginx.org/en/CHANGES-1.6、http://nginx.org/ en/CHANGES-1.8)。

Bugfix: requests might hang if resolver was usedand a timeout 
      occurred during a DNS request. 

請考慮升級到Nginx 1.6.2、1.7.5或者在Nginx本機部署dnsmasq提升DNS解析性能。

(3) 代理超時設置

Nginx配置如下所示。

upstream backend_server { 
    server 192.168.61.1:9080 max_fails=2 fail_timeout=10s weight=1; 
    server 192.168.61.1:9090 max_fails=2 fail_timeout=10s weight=1; 
} 
server { 
    …… 
    location /test { 
       proxy_connect_timeout 5s; 
       proxy_read_timeout 5s; 
       proxy_send_timeout 5s; 
  
       proxy_next_upstream error timeout; 
       proxy_next_upstream_timeout 0; 
       proxy_next_upstream_tries 0; 
  
       proxy_pass http://backend_server; 
       add_header upstream_addr $upstream_addr; 
    } 
} 

backend_server定義了兩個上游服務器192.168.61.1:9080(返回hello)和192.168.61.1:9090(返回hello2)。

如上指令主要有三組配置：網絡連接/讀/寫超時設置、失敗重試機制設置、upstream存活超時設置。

網絡連接/讀/寫超時設置。

• proxy_connect_timeout time：與后端/上游服務器建立連接的超時時間，默認為60s，此時間不超過75s。
• proxy_read_timeout time：設置從后端/上游服務器讀取響應的超時時間，默認為60s，此超時時間指的是兩次成功讀操作間隔時間，而不是讀取整個響應體的超時時間，如果在此超時時間內上游服務器沒有發送任何響應，則Nginx關閉此連接。
• proxy_send_timeout time：設置往后端/上游服務器發送請求的超時時間，默認為60s，此超時時間指的是兩次成功寫操作間隔時間，而不是發送整個請求的超時時間，如果在此超時時間內上游服務器沒有接收任何響應，則Nginx關閉此連接。

對于內網高并發服務，請根據需要調整這幾個參數，比如內網服務TP999為1s，可以將連接超時設置為100~500毫秒，而讀超時可以為1.5~3秒左右。

失敗重試機制設置。

proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 |http_403 | http_404 | non_idempotent | off ...： 

配置什么情況下需要請求下一臺上游服務器進行重試。默認為“errortimeout”。error表示與上游服務器建立連接、寫請求或者讀響應頭出錯。timeout表示與上游服務器建立連接、寫請求或者讀響應頭超時。invalid_header表示上游服務器返回空的或錯誤的響應頭。http_XXX表示上游服務器返回特定的狀態碼。non_idempotent表示RFC-2616定義的非冪等HTTP方法(POST、LOCK、PATCH)，也可以在失敗后重試下一臺上游服務器(即默認冪等方法GET、HEAD、PUT、DELETE、OPTIONS、TRACE才可以重試)。off表示禁用重試。

重試不能無限制進行，因此，需要如下兩個指令控制重試次數和重試超時時間。

• proxy_next_upstream_tries number：設置重試次數，默認0表示不限制，注意此重試次數指的是所有請求次數(包括第一次和之后的重試次數之和)。
• proxy_next_upstream_timeout time：設置重試最大超時時間，默認0表示不限制。

即在proxy_next_upstream_timeout時間內允許proxy_next_upstream_tries次重試。如果超過了其中一個設置，則Nginx也會結束重試并返回客戶端響應(可能是錯誤碼)。

如下配置表示當error/timeout時重試upstream中的下一臺上游服務器，如果重試的總時間超出了6s或者重試了1次，則表示重試失敗(因為之前已經請求一次了，所以還能重試一次)，Nginx結束重試并返回客戶端響應。

proxy_next_upstream error timeout; 
proxy_next_upstream_timeout 6s; 
proxy_next_upstream_tries 2; 

(4) upstream存活超時設置

max_fails和fail_timeout：配置什么時候Nginx將上游服務器認定為不可用/不存活。當上游服務器在fail_timeout時間內失敗了max_fails次，則認為該上游服務器不可用/不存活。并在接下來的fail_timeout時間內從upstream摘掉該節點(即請求不會轉發到該上游服務器)。

什么情況下被認定為失敗呢?其由 proxy_next_upstream定義，不過，不管 proxy_next_upstream如何配置，error, timeout and invalid_header 都將被認為是失敗。

如server 192.168.61.1:9090max_fails=2 fail_timeout=10s;表示在10s內如果失敗了2次，則在接下來的10s內認定該節點不可用/不存活。這種存活檢測機制是只有當訪問該上游服務器時，采取惰性檢查，可以使用ngx_http_upstream_check_module配置主動檢查。

max_fails設置為0表示不檢查服務器是否可用(即認為一直可用)，如果upstream中僅剩一臺上游服務器時，則該服務器是不會被摘除的，將從不被認為不可用。

(5) ngx_lua超時設置

當我們使用ngx_lua時，也請考慮設置如下網絡連接/讀/寫超時。

lua_socket_connect_timeout  100ms; 
lua_socket_send_timeout    200ms; 
lua_socket_read_timeout    500ms; 

在使用lua時，我們會按照如下策略進行重試。

if (status == 502 or status == 503 or status ==504) and request_time < 200 then 
    resp =capture(proxy_uri) 
    status =resp.status 
    body =resp.body 
   request_timerequest_time = request_time + tonumber(var.request_time) * 1000 
end 

即如果狀態碼是500/502/503/504時，并且該次請求耗時在200毫秒以內，則我們進行一次重試。

2. Twemproxy

Twemproxy是Twitter開源的Redis和Memcache代理中間件，其目的是減少與后端緩存服務器的連接數。

• timeout：表示與后端服務器建立連接、接收響應的超時時間，默認永不超時。
• server_retry_timeout和server_failure_limit：當開啟auto_eject_hosts，即當后端服務器不可用時自動摘除這些節點并在一定時間后進行重試。server_failure_limit設置連續失敗多少次后將節點臨時摘除，server_retry_timeout設置摘除節點后等待多久進行重試，從而保證不永久性的將節點摘除。

二、Web容器超時

筆者生產環境用的Java Web容器是Tomcat，本部分將以Tomcat8.5作為例子進行講解。

• connectionTimeout：配置與客戶端建立連接超時時間，從接收到連接后在配置的時間內還沒有接收到客戶端請求行時，將被認定為連接超時，默認為60000(60s)。
• socket.soTimeout：從客戶端讀取請求數據的超時時間，默認同connectionTimeout，NIO and NIO2 支持該配置。
• asyncTimeout：Servlet 3異步請求的超時時間，默認為30000(30s)。
• disableUploadTimeout 和connectionUploadTimeout：當配置disableUploadTimeout為false時(默認為true，和connectionTimeout一樣)，文件上傳將使用connectionUploadTimeout作為超時時間。
• keepAliveTimeout和maxKeepAliveRequests：和Nginx配置類似。keepAliveTimeout默認為connectionTimeout，配置-1表示永不超時。maxKeepAliveRequests默認為100。

三、中間件客戶端超時與重試

JSF是京東自研的SOA框架，主要有三個組件：注冊中心、服務提供端、服務消費端。

• 首先是服務提供端/消費端與注冊中心之間的進行服務注冊/發現時可以配置timeout(調用注冊中心超時時間，默認為5s)和connectTimeout(連接注冊中心的超時時間，默認為20s)。
• 服務提供端可以配置timeout(服務端調用超時，默認為5s)。
• 服務消費端可以配置timeout(調用端調用超時時間，默認為5s)，connectTimeout(建立連接超時時間，默認為5s)，disconnectTimeout(斷開連接/等待結果超時時間，默認為10s)，reconnect(調用端重連死亡服務端的間隔，配置小于0表示不重連，默認為10s)，heartbeat(調用端往服務端發心跳包間隔，配置小于0代表不發送，默認為30s)，retries(失敗后重試次數，默認0不重試)。

Dubbo也有類似的配置，在此就不闡述了。

JMQ是京東消息中間件，主要有四個組件：注冊中心、Broker(JMQ的服務端實例，生產和消費消息都跟它交互)、生產者、消費者。

• 首先是生產者/消費者與Broker進行發送/接收消息時可以配置connectionTimeout(連接超時)、sendTimeout(發送超時)、soTimeout(讀超時)。
• 生產者可以配置retryTimes(發送失敗后的重試次數，默認為2次)。
• 消費者可以配置pullTimeout(長輪詢超時時間，即拉取消息超時時間)、maxRetrys(最大重試次數，對于消費者要允許無限制重試，即一直拉取消息)、retryDelay(重試延遲，通過exponential配置延遲增加倍數一直增加到maxRetryDelay)、maxRetryDelay(最大重試延遲)。消費者還需要配置應答超時時間(服務端需要等待客戶端返回應答才能移除消息，如果沒有應答返回，則會等待應答超時，在這段時間內鎖定的消息不能被消費，必須等待超時后才能被消費)。

對于消息中間件我們實際應用中關注超時配置會少一些，因為生產者默認配置了重試次數，可能會存在重復消息，消費者需要進行去重處理。

CXF可以通過如下方式配置CXF客戶端連接超時、等待響應超時和長連接。

HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy(); 
httpClientPolicy.setConnectionTimeout(30000);//默認為30s 
httpClientPolicy.setReceiveTimeout(60000); //默認為60s 
httpClientPolicy.setConnection(ConnectionType.KEEP_ALIVE);//默認為Keep- Alive 
((HTTPConduit)client.getConduit()).setClient(httpClientPolicy); 

Httpclient 4.2.x可以通過如下代碼配置網絡連接、等待數據超時時間。

HttpParams params = new BasicHttpParams(); 
//設置連接超時時間 
Integer CONNECTION_TIMEOUT = 2 * 1000;    //設置請求超時2秒鐘 
Integer SO_TIMEOUT = 2 * 1000;        //設置等待數據超時時間2秒鐘 
Long CONN_MANAGER_TIMEOUT = 1L * 1000;        //定義了當從ClientConnectionManager中檢索ManagedClientConnection實例時使用的毫秒級的超時時間 
params.setIntParameter(CoreConnectionPNames.CONNECTION_TIMEOUT,CONNECTION_TIMEOUT); 
params.setIntParameter(CoreConnectionPNames.SO_TIMEOUT,SO_TIMEOUT); 
//在提交請求之前，測試連接是否可用 
params.setBooleanParameter(CoreConnectionPNames.STALE_CONNECTION_CHECK,true); 
//這個參數期望得到一個java.lang.Long類型的值。如果這個參數沒有被設置，則連接請求就不會超時（無限大的超時時間） 
params.setLongParameter(ClientPNames.CONN_MANAGER_TIMEOUT,CONN_MANAGER_TIMEOUT); 
PoolingClientConnectionManager conMgr = new PoolingClientConnectionManager(); 
conMgr.setMaxTotal(200);//設置最大連接數 
//是路由的默認最大連接（該值默認為2），限制數量實際使用DefaultMaxPerRoute并非MaxTotal 
//設置過小，無法支持大并發(ConnectionPoolTimeoutException: Timeout waiting for connection frompool)，路由是對maxTotal的細分 
conMgr.setDefaultMaxPerRoute(conMgr.getMaxTotal());//（目前只有一個路由，因此讓他等于最大值） 
  
//設置訪問協議 
conMgr.getSchemeRegistry().register(new Scheme("http",80, PlainSocketFactory. getSocketFactory())); 
conMgr.getSchemeRegistry().register(new Scheme("https",443, SSLSocketFactory. getSocketFactory())); 
httpClient = newDefaultHttpClient(conMgr, params); 
httpClient.setHttpRequestRetryHandler(newDefaultHttpRequestRetryHandler(0, false)); 

因為我們使用http connection連接池，所以需要配置CONN_MANAGER_TIMEOUT，表示從連接池獲取http connection的超時時間。

此處還通過httpClient.setHttpRequestRetryHandler(newDefaultHttpRequestRetry Handler(0, false))配置了請求重試策略(默認重試3次)。當執行請求時遇到異常時會調用retryRequest來判斷是否進行重試，而retryRequest在以下情況不會進行重試：達到重試次數、服務器不可達、連接被拒絕、連接終止、請求已發送。而冪等HTTP方法的請求、requestSentRetryEnabled=true且請求還未成功發送時可以重試。

如果響應是503錯誤狀態碼時，如上重試機制是不可用的，則可以考慮使用AutoRetryHttpClient客戶端，其可以配置ServiceUnavailableRetryStrategy，默認實現為DefaultServiceUnavailableRetryStrategy，可以配置重試次數maxRetries和重試間隔retryInterval。每次重試之前都會等待retryInterval毫秒時間。

假設我們服務有多個機房提供，其中一個機房服務出現問題時應該自動切到另一個機房，可以考慮使用如下方法。

public static String get(List<String> apis, Object[] args, String encoding,Header[] headers, Integer timeout) throws Exception { 
    Stringresponse = null; 
    for(String api : apis) { 
        String uri =UriComponentsBuilder.fromHttpUrl(api).buildAndExpand(args). toUriString(); 
       response = HttpClientUtils.getDataFromUri(uri, encoding, headers,timeout); 
        //如果失敗了，重試一次 
        if(Objects.equal(response, HTTP_ERROR)){ 
            continue; 
        } 
        //如果域名解析失敗重試 
        if(Objects.equal(response,HTTP_UNKNOWN_HOST_ERROR)) { 
           response = HTTP_ERROR; //掉用方根據這個判斷是否有問題 
            continue; 
        } 
        if(Objects.equal(response,HTTP_SOCKET_TIMEOUT_ERROR)) { 
           response = HTTP_ERROR; //調用方根據這個判斷是否有問題 
            continue; 
        } 
        return response; 
    } 
    return response; 
} 

參數傳入不同機房的API即可，當其中一個不可用自動重試另一個機房的API。

【本文是51CTO專欄作者“張開濤”的原創文章，作者微信公眾號：開濤的博客( kaitao-1234567)】

戳這里，看該作者更多好文