ChsHttpUpstreamModule
Contents |
[edit] 鎽樿
璇ユā鍧椾负鍚庣鏈嶅姟鍣ㄦ彁渚涚畝鍗曠殑璐熻浇鍧囪 锛堣疆寰皟搴﹀拰瀹㈡埛绔 IP锛夈
绀轰緥锛
[edit] 鎸囦护
[edit] ip_hash
璇硶: ip_hash
榛樿鍊: 鏃
璇: upstream
This directive causes requests to be distributed between upstreams based on the IP-address of the client.
The key for the hash is the class-C network address of the client. This method guarantees that the client request will always be transferred to the same server. But if this server is considered inoperative, then the request of this client will be transferred to another server. This gives a high probability clients will always connect to the same server.
It is not possible to combine ip_hash and weight methods for connection distribution. If one of the servers must be removed for some time, you must mark that server as *down*.
绀轰緥锛
[edit] server
璇硶: server name [parameters]
榛樿鍊: 鏃
璇: upstream
Directive assigns the name and the parameters of server. For the name it is possible to use a domain name, an address, port or unix socket. If domain name resolves to several addresses, then all are used.
- weight = NUMBER - set weight of the server, if not set weight is equal to one.
- max_fails = NUMBER - number of unsuccessful attempts at communicating with the server within the time period (assigned by parameter fail_timeout) after which it is considered inoperative. If not set, the number of attempts is one. A value of 0 turns off this check. What is considered a failure is defined by proxy_next_upstream or fastcgi_next_upstream (except http_404 errors which do not count towards max_fails).
- fail_timeout = TIME - the time during which must occur *max_fails* number of unsuccessful attempts at communication with the server that would cause the server to be considered inoperative, and also the time for which the server will be considered inoperative (before another attempt is made). If not set the time is 10 seconds. fail_timeout has nothing to do with upstream response time, use proxy_connect_timeout and proxy_read_timeout for controlling this.
- down - marks server as permanently offline, to be used with the directive ip_hash.
- backup - (0.6.7 or later) only uses this server if the non-backup servers are all down or busy
绀轰緥锛
[edit] upstream
璇硶: upstream name { ... }
榛樿鍊: 鏃
璇: http
杩欎釜鎸囦护鎻忚堪浜嗕竴涓湇鍔″櫒鐨勯泦鍚堬紝璇ラ泦鍚堝彲琚敤浜 proxy_pass 鍜 fastcgi_pass 鎸囦护涓紝浣滀负涓涓崟鐙殑瀹炰綋銆
杩欎簺鏈嶅姟鍣ㄥ彲浠ユ槸鐩戝惉鍦ㄤ笉鍚岀殑绔彛锛屽彟澶栵紝骞跺彂浣跨敤鍚屾椂鐩戝惉 TCP 绔彛鍜 Unix 濂楁帴瀛楃殑鏈嶅姟鍣ㄦ槸鍙兘鐨勩
杩欎簺鏈嶅姟鍣ㄨ兘琚垎閰嶄笉鍚岀殑鏉冮噸銆傚鏋滄病鏈夋寚瀹氾紝鍒欓兘涓轰竴銆
绀轰緥锛
Requests are distributed according to the servers in round-robin manner with respect of the server weight.
For example of every 7 seven requests given above they will be distributed like this: 5 requests on backend1.example.com and one request to the second and the third of server. If with an attempt at the work with the server error occurred, then the request will be transmitted to the following server and then until all workers of server not are tested. If successful answer is not succeeded in obtaining from all servers, then to client will be returned the result of work with the last server.
[edit] 鍙橀噺
鑷増鏈 0.5.18 涔嬪悗锛屽彲閫氳繃 log_module 妯″潡灏嗗彉閲忓煎啓鍏ユ棩蹇椼
绀轰緥锛
log_format timing '$remote_addr - $remote_user [$time_local] $request ' 'upstream_response_time $upstream_response_time ' 'msec $msec request_time $request_time'; log_format up_head '$remote_addr - $remote_user [$time_local] $request ' 'upstream_http_content_type $upstream_http_content_type';
[edit] $upstream_addr
Address of the upstream server that handled the request
[edit] $upstream_cache_status
Appeared in 0.8.3. Possible values:
- MISS
- EXPIRED - expired, request was passed to backend
- UPDATING - expired, stale response was used due to proxy/fastcgi_cache_use_stale updating
- STALE - expired, stale response was used due to proxy/fastcgi_cache_use_stale
- HIT
[edit] $upstream_status
Upstream server status of the answer
[edit] $upstream_response_time
Response time in milliseconds. Several answers are divided by commas and colons.
[edit] $upstream_http_$HEADER
Arbitrary HTTP protocol headers, for example:
$upstream_http_host