Quickly understand the principles and configurations of Nginx load balancing and nginx Load Balancing
What is Server Load balancer?
When a server has more traffic per unit time, the server is under greater pressure and exceeds its capacity, the server will crash. To avoid server crashes and provide a better user experience, we use Server Load balancer to share the server pressure.
We can create many servers to form a server cluster. When users access a website, they first access an intermediate server, select a low-pressure server in the server cluster for the intermediate server, and then introduce the access request to the server. In this way, each user's access will ensure that the pressure on each server in the server cluster is balanced, and the server pressure is shared to avoid server crashes.
Server Load balancer is implemented using reverse proxy.
Common Load Balancing Methods 1. Round Robin (default)
Each request is distributed to different backend servers one by one in chronological order. If the backend servers are down, they can be removed automatically.
upstream backserver { server 192.168.0.14; server 192.168.0.15;}
2. weight
Specify the polling probability. weight is proportional to the access ratio, which is used for uneven backend server performance.
Status.
upstream backserver { server 192.168.0.14 weight=3; server 192.168.0.15 weight=7;}
The higher the weight, the higher the probability of being accessed. In the preceding example, the weights are 30% and 70%, respectively.
3. Positioning
There is a problem in the above method: In the Server Load balancer system, if the user logs on to a server, the second request of the user is because we are a Server Load balancer system, every request will be directed to another server in the server cluster. If a user who has logged on to a server is directed to another server, the login information will be lost. This is obviously inappropriate.
We can use the ip_hash command to solve this problem. If the customer has accessed a server, when the user accesses the server again, the request will be automatically located to the server through the hash algorithm.
Each request is allocated according to the hash result of the access ip address, so that each visitor accesses a backend server at a fixed time, which can solve the session problem.
upstream backserver { ip_hash; server 192.168.0.14:88; server 192.168.0.15:80;}
4. fair (third party)
Requests are allocated based on the response time of the backend server. Requests with short response time are prioritized.
upstream backserver { server server1; server server2; fair;}
5. url_hash (third-party)
Requests are allocated based on the hash result of the access url so that each url is directed to the same backend server. The backend server is effective when it is cached.
upstream backserver { server squid1:3128; server squid2:3128; hash $request_uri; hash_method crc32;}
The status of each device is set:
Down indicates that the server before a ticket is not involved in the load
The default weight value is 1. The larger the weight value, the larger the load weight.
Max_fails: the default number of failed requests is 1. If the maximum number of failed requests is exceeded, an error defined by the proxy_next_upstream module is returned.
Fail_timeout: The pause time after max_fails failed.
Backup: Requests the backup machine when all other non-backup machines are down or busy. Therefore, this machine is under the least pressure.
Configuration instance:
# User nobody; worker_processes 4; events {# maximum number of concurrencies worker_connections 1024;} http {# list of servers to be selected upstream myproject {# ip_hash command to introduce the same user to the same server. Ip_hash; server 125.219.42.4 fail_timeout = 60 s; server 172.31.2.183;} server {# listening port listen 80; # location/{# Which server list to select under the root directory proxy_pass https: // myproject ;}}}