upstream configure
upstream backend{
server 192.168.1.11:8080 weight=1;
server 192.168.1.12:8080 weight=2;
}
weight: use weight to configure, the default is 1, the higher the weight, the more requests will be allocated
and then use proxy_pass to Process user request
location / {
proxy_pass http://backend ;
}
Load balancing algorithm
Load balancing is used to solve the problem of how to select upstream server when user request arrives. By default, round-robin is used.
round-robin: round- robin , forward the request to the
upstream server in a round-robin manner, and implement weight-based round-robin by cooperating with the weight configuration
ip_hash;
server 192.168.1.11:8080 weight=1;
server 192.168.1.12:8080 weight=2;
}
hash key [consistent]: Hash a key or use a consistent hash algorithm for load balancing
Hash algorithm
upstream backend {
hash $uri
server 192.168.1.11:8080 weight=1;
server 192.168.1.12:8080 weight=2;
}
hash consistency algorithm
upstream backend{
hash $consistent_key consistent;
server 192.168.1.11:8080 weight=1;
server 192.168 .1.12:8080 weight=2;
}
least_conn: load balance requests to upstream servers with the least active connections.
least_time: minimum average response time for load balancing (available in commercial version)
fail to retry
Specify the number of failures per upstream server by configuring max_fails and max_timeout
upstream backend {
server 192.168.1.11:8080 max_fails=2 fail_timeout=10s weight=1;
server 192.168.1.12:8080 max_fails=2 fail_timeout=10s weight=1;
}
location /{
proxy_connect_timeout 5s;
proxy_read_timeout 5s;
proxy_timeout 5s;
proxy_next_upstream error timeout;
proxy_next_upstream_timeout 10s;
proxy_next_upstream_tries 2;
proxy_pass http://backend;
add_header upstream_add $upstream_add;}
TCP heartbeat check
interval: monitoring time interval
fall: how many times the monitoring fails and the upstream server is marked as not alive
rise: how many times the detection succeeds, the upstream server is marked as alive and can process the request
timeout: monitoring the request timeout time and configuring the
upstream backend {
server 192.168.1.11:8080 weight=1;
server 192.168.1.12:8080 weight=2;
check interval=3000 rise=1 fall=3 timeout=2000 type=tcp;
}
HTTP heartbeat check
check_http_send: Send HTTP request content when checking
check_http_expect_alive: The server returns a matching response status code
upstream backend{
server 192.168.1.11:8080 weight=1;
server 192.168.1.12:8080 weight=2;
check interval=3000 rise=1 fall=3 timeout=2000 type=http;
check_http_send "HEAD /status HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;}
Note: The check time interval cannot be too short, otherwise the server may hang due to too many heartbeat check packets
. This article uses openresty/1.11.2.1 (corresponding to nginx-1.11.2), and the nginx_upstream_check_module patch (check_1.9.2) needs to be applied before installation. +.patch) to the Nginx directory to execute the shell:
patch -p0</usr/servers/nginx_upstream_check_module-master/check_1.9.2+.patch
If the patch is not installed, the ngixn_upstream_check_module module will not work. It is recommended to use wireshark to capture packets to see if it works.
original information
Author: Le Lele
Link: https://www.jianshu.com/p/55aee46a8a0c
Source: Jianshu
The copyright belongs to the author. For commercial reprints, please contact the author for authorization, and for non-commercial reprints, please indicate the source.