Preface: A very important function of Nginx-proxy, including forward proxy and reverse proxy. The core difference between the two proxies is that the forward proxy is the client, while the reverse proxy is the server. And how to implement reverse proxy through Nginx. After understanding the reverse proxy of Nginx, you can try to implement another important function-load balancing through the reverse proxy of Nginx.
1. The origin of load balancing
The early system architecture is basically as shown in the following figure: the
client sends multiple requests to the server, the server processes the requests, and some may interact with the database, and the server returns the results to the client after processing.
This architecture model is more suitable for the early system when the system is relatively single and there are relatively few concurrent requests, and the cost is also low. However, with the continuous increase in the amount of information, the rapid increase in the amount of access and data, and the increase in system business complexity, this architecture will cause the server's corresponding client requests to become increasingly slow, and when the amount of concurrency is particularly large, it is easy to cause the server Crash directly. Obviously this is a problem caused by the bottleneck of server performance, so how to solve this situation?
Our first thought may be to upgrade the server configuration, such as increasing the CPU execution frequency, increasing the memory, etc. to improve the physical performance of the machine to solve this problem, but we know that Moore's Law is becoming more and more invalid, and the performance improvement of hardware can no longer meet the increasing demand. Demand. The most obvious example is that on the day of Tmall Double Eleven, the instantaneous visit volume of a hot-selling product is extremely large, so similar to the above system architecture, adding machines to the existing top-level physical configuration is not possible Meet the demand. So what to do?
In the above analysis, we removed the method of increasing the physical configuration of the server to solve the problem. That is to say, the vertical solution to the problem does not work, so how to increase the number of servers horizontally? At this time, the concept of clustering came into being. A single server could not solve it. We increased the number of servers, and then distributed the request to each server. The original request was concentrated on a single server instead of the request distributed to multiple servers. The load is distributed to different servers, which is what we call "load balancing".
Load balancing perfectly solves the problem of the 
hardware performance bottleneck of a single server, but how to achieve load balancing subsequently? How does the client know which server to send the request to for processing?
Two, Nginx achieves load balancing
Nginx server is an intermediary between the client and the server. Through the reverse proxy function explained in the previous blog, the request sent by the client first passes through Nginx, and then the request is distributed to the corresponding server through Nginx according to the corresponding rules .
The main configuration instructions are the pass_proxy instruction and the upstream instruction in the previous lecture. Load balancing is mainly realized through specialized hardware devices or software algorithms. The load balancing effect achieved by hardware equipment is good, efficient, and stable, but the cost is high. The load balancing realized by software mainly depends on the selection of the balancing algorithm and the robustness of the program. Equalization algorithms are mainly divided into two categories:
Static load balancing algorithm: It mainly includes round-robin algorithm, weighted round-robin algorithm based on ratio or weighted round-robin algorithm based on priority.
Dynamic load balancing algorithm: It mainly includes the least connection optimization algorithm based on task volume, the fastest response priority algorithm based on performance, prediction algorithm and dynamic performance allocation algorithm.
Static load balancing algorithms can perform better in general network environments, and dynamic load balancing algorithms are more suitable for complex network environments.
Examples:
1. Ordinary polling algorithm
This is the default polling algorithm of Nginx.
例子：两台相同的Tomcat服务器
重点：tomcat1用自己所拥有的，不作任何修改，我使用的端口为8888，你们可能为8080
通过 localhost:8888访问Tomcat1，
通过 localhost:8088访问Tomcat2，
现在我们要输入 localhost 这个地址，
可以在这两个Tomcat服务器之间进行交替访问。
1.1. Decompress a new tomcat and modify the port number. Then modify the Tomcat home page to make it distinguishable when visiting these two pages. As follows:
Modify the port number file to conf/server.xml
(1) The first place 8005 is changed to 8006
(2) The second place 8080 is changed to 8088
(3) The third place 8009 is changed to 8010
The path of the homepage is changed to: webapps/ ROOT/index.jsp
2. Modify the configuration file nginx.conf of nginx
upstream OrdinaryPolling {
server 127.0.0.1:8888;
server 127.0.0.1:8088;
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://OrdinaryPolling;
index index.html index.htm index.jsp;
}
}
3. Start nginx. Then enter the localhost address in the browser and watch the page change:
2. Weighted polling based on proportionality The
above two Tomcat servers are basically accessed alternately. But here we have a requirement:
Due to the higher configuration of the Tomcat1 server, we hope that the server will accept more requests, while the Tomcat2 server has a lower configuration and hope that it will handle relatively fewer requests.
Then the weighted polling mechanism is used at this time.
The nginx.conf configuration file is as follows:
upstream OrdinaryPolling {
server 127.0.0.1:8888 weight=5;
server 127.0.0.1:8088 weight=2;
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://OrdinaryPolling;
index index.html index.htm index.jsp;
}
}
In fact, compared with the above non-weighted polling method, there is an additional weight instruction in the upstream instruction. This command is used to configure the weight of the previous request processing, the default value is 1.
That is to say: the first type of unweighted ordinary polling, in fact, its weighted value weight is 1.
Let's look at the corresponding results on the page:
Obviously, the 8888 port number appears more often, and the more the number of trials, the closer to the proportion we configured.
3. Based on IP routing load,
we know that when a request is processed by a server, the server will save related session information, such as session, but if the request is not processed by the first server, it will be polled to the second server through nginx , Then this server has no session information.
The most typical example: the first time a user enters a system requires login authentication. First, the request is redirected to the Tomcat1 server for processing. The login information is stored on Tomcat1. At this time, other operations are required. The request may be polled to the second Tomcat2, then because Tomcat2 does not save the session information, it will think that the user is not logged in, and then continue to log in once. If there are multiple servers, log in for each first visit, which is obviously It greatly affects the user experience.
One of the problems that arises here is session sharing in a cluster environment. How to solve this problem?
There are usually two methods:
(1) The first method is to select a middleware and save the login information on a middleware. This middleware can be a database like Redis. Then for the first login, we save the session information in Redis. When jumping to the second server, we can first go to Redis to check whether there is login information. If so, we can directly perform the operations after login. No need to log in repeatedly.
(2) The second method is to divide the client's IP address, each time the request sent from the same IP address is distributed to the same Tomcat server, then there will be no session sharing problem.
And nginx's mechanism based on IP routing load is the second form of appeal. The approximate configuration is as follows:
upstream OrdinaryPolling {
ip_hash;
server 127.0.0.1:8888 weight=5;
server 127.0.0.1:8088 weight=2;
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://OrdinaryPolling;
index index.html index.htm index.jsp;
}
}
ps : We have added the ip_hash instruction to the upstream instruction block. This instruction tells the nginx server that all requests sent by clients with the same IP address will be distributed to the same Tomcat server for processing.
4. Load distribution based on server response time load
according to the time the server processes the request. The faster the request is processed, the shorter the response time is, the priority is allocated. The approximate configuration is as follows:
upstream OrdinaryPolling {
server 127.0.0.1:8888 weight=5;
server 127.0.0.1:8088 weight=2;
fair;
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://OrdinaryPolling;
index index.html index.htm index.jsp;
}
}
By adding the fair command. The load is performed according to the time the server processes the request.
5. Realize load balancing for different domain names. The
approximate configuration of is as follows:
upstream wordbackend {
server 127.0.0.1:8888;
server 127.0.0.1:8088;
}
upstream pptbackend {
server 127.0.0.1:8082;
server 127.0.0.1:8083;
}
server {
listen 80;
server_name localhost;
location /word/ {
proxy_pass http://wordbackend;
index index.html index.htm index.jsp;
}
location /ppt/ {
proxy_pass http://pptbackend;
index index.html index.htm index.jsp;
}
}
By cooperating with the location command block, we can also achieve load balancing for different domain names.