1. Three common scheduling algorithms
Polling: nginx load balancing default policy, scheduled one by one in chronological order, suitable for situations where the connection status is short and the backend server configuration is the same.
Weight: The higher the weight, the higher the frequency of access. It is suitable for situations where the connection status is short and the configuration of the backend server is large.
ip_hash: According to the client's IP process allocation, it ensures that the same client can access a fixed server node every time, which is suitable for scenarios where users conduct file transfers for a long time. ip_hash cannot provide health monitoring function
Configuration method
NGINX configuration load balancing is mainly used to upload the file.
1. The upstream module should be placed in the configured http{} tag
2. The default algorithm of the upstream module is wrr (weighted round-robin)
Allocation algorithm
Nginx's upstream supports 5 allocation methods. The following will introduce in detail. The first three are Nginx natively supported allocation methods, and the latter two are third-party supported allocation methods.
1. Investigation
Polling is the default allocation method of upstream, that is, each request is assigned to different backend servers in chronological order. If a backend server is down, it can be automatically eliminated.
upstream backend {
server 192.168.1.101:8888;
server 192.168.1.102:8888;
server 192.168.1.103:8888;
}
2. Weight (weight ratio)
The enhanced version of polling can specify the polling ratio, and the weight is proportional to the access probability, and it is mainly used in the case of heterogeneous back-end servers.
upstream backend {
server 192.168.1.101 weight=1;
server 192.168.1.102 weight=2;
server 192.168.1.103 weight=3;
}
3、ip_hash
Each request is assigned according to the hash result of accessing the IP (i.e., Nginx's pre-server or client IP), so that each visitor will access a back-end server in a fixed manner, which can solve the session consistency problem.
upstream backend {
ip_hash;
server 192.168.1.101:7777;
server 192.168.1.102:8888;
server 192.168.1.103:9999;
}
Notice:
1. When the load scheduling algorithm is ip_hash, the state of the backend server in load balancing scheduling cannot be weight and backup.
2. Causes load imbalance.
4、fair
As the name suggests, fairly allocates requests according to the response time (rt) of the backend server. Backend servers with short response time, that is, small rt will be given priority. If you need to use this scheduling algorithm, you must download Nginx's upstr_fair module.
upstream backend {
server 192.168.1.101;
server 192.168.1.102;
server 192.168.1.103;
fair;
}
5. url_hash, currently use consistent_hash to replace url_hash
Similar to ip_hash, but the request is allocated according to the hash result of accessing the url, so that each url is directed to the same backend server, which is mainly used in the scenario when the backend server is cached.
upstream backend {
server 192.168.1.101;
server 192.168.1.102;
server 192.168.1.103;
hash $request_uri;
hash_method crc32;
}
Among them, hash_method is the hash algorithm used. It should be noted that at this time, parameters such as weight cannot be added to the server statement.
Tip: url_hash uses cache service business, memcached, squid, varnish. Features: Each rs is different.
2. Equipment status
From the above example, it is not difficult to see that the syntax of the server instruction in upstream is as follows: server address [parameters]
Parameter description:
server: keyword, required.
address: host name, domain name, IP or unix socket, you can also specify the port number, which is required.
parameters: Optional parameters, the optional parameters are as follows:
: Indicates that the server has been disabled
: Indicates that the current server is a backup server, and only if other non-backup backend servers are hung up or are very busy will be assigned to the request.
: Indicates the current server load weight, the greater the weight, the greater the chance of being requested. The default is 1.
4.max_fails and fail_timeout are generally used in association. If a server fails to connect max_fails within fail_timeout time, then Nginx will think that it has hanged, so it will no longer request it in fail_timeout time. Fail_timeout is 10s by default, and max_fails is 1 by default. That is, the default is that as long as an error occurs, the server is considered to have hanged. If max_fails is set to 0, this check is cancelled.
An example is as follows:
upstream backend {
server weight=5;
server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
server unix:/tmp/backend3;
}
This is the end of this article about the implementation of scheduling algorithms in nginx. For more related nginx scheduling algorithm content, please search for my previous articles or continue browsing the related articles below. I hope everyone will support me in the future!