Django project deployment (four) NGINX to achieve load balancing

You can refer to the blog: https://blog.51cto.com/gaowenlong/1887997
https://blog.csdn.net/z406245159/article/details/72821285
https://www.cnblogs.com/jsonhc/p/7199295. html?utm_source=itdadao&utm_medium=referral

负载均衡:
A---应用服务器：运行项目的服务器 同一个项目 单独的存在的时候正常运行项目 web服务器运行 192.168.1.186
（上面有 nginx ，uwsgi， 虚拟环境 ，80端口 ，mysql数据库 ）
B----应用服务器：运行项目的服务器 同一个项目 单独的存在的时候正常运行项目 web服务器运行 192.168.1.187
C---应用服务器：运行项目的服务器 同一个项目 单独的存在的时候正常运行项目 web服务器运行 192.168.1.188
D---反向代理服务器：192.168.1.189，用户通过访问p服务器的地址之后间接的来访问A/B/C应用服务器其中的一台服务器的项目
E---服务器 安装mysql数据库 47.100.xxx.xxx

如何去做反向代理配置nginx web服务器

According to what we did before, there are now two web servers 1.186 and 1.187. Load balancing server 1.189 only installs NGINX,
Insert picture description here
first confirm that NGINX of 189 can operate normally

One-to-one reverse proxy (just understand)

当url 匹配路径的时候 /
一对一的反向代理 访问192.168.1.189 ---> 187
proxy_pass http://192.168.1.187;

vim /etc/nginx/conf.d/default.conf
Insert picture description here
192.168.1.189/admin/login
access (the content of 187 is accessed at this time)

This is the interface of 186 (in order to distinguish 187)
Insert picture description here

One-to-many load balancing (186,187)

Insert picture description here

1. Weighted

Specify the polling probability, the weight is proportional to the access ratio, used in the case of uneven back-end server performance

upstream local_servers {
    server 192.168.1.187:8996 weight=1;
    server 192.168.1.185:8997 weight=1;
   server 192.168.1.185:8997 weight=1;
}

upstream local_servers1 {
    server 192.168.1.187 weight=1;
    server 192.168.1.185 weight=1;
   server 192.168.1.185 weight=1;
}


server {
        listen       80;
        server_name  localhost;
        charset utf-8;
        location / {
            proxy_pass http://local_servers1;
				proxy_set_header Host $host;       // $host就是nginx代理服务器
 			proxy_set_header X-Real-IP $remote_addr;   //客户端真实ip
 			proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;    
proxy_buffering off;               //代理缓存删除

        }
    }

#The frequency of appearance is about 1:1. This is the role of weight in upstream, which means that weight represents weight. The greater the weight, the greater the probability that the request will be forwarded to this address.

After modification, restart systemctl restart nginx.service to
Insert picture description here
access, see the effect

split line=

2. ip_hash

Comment out the weight just now and replace it with ip_hash.
Each request is allocated according to the hash result of the access ip, so that each visitor can access a back-end server fixedly, which can solve the session problem.
Insert picture description here
When accessing, a session value will be generated and written in the database. inner

管理员在登录的时候把用户名存session数据库中,生成一条session数据的时候,session_data:用户名， session_key:django
自动生成写入数据库中django_session ， 同时又把session_key存储到了cookie

Insert picture description here
It can be seen that the sessionid at the beginning of lvn is stored in the database.

At this time, when all web projects access the same database, there is no problem in using weight. But if you are accessing different databases, such as the databases of your own machine, there will be problems at this time. When you access the page, he will access the contents of the two databases. He will always cycle on the login page. Use ip_hash to deal with session problems. The
session default data is stored in the database, and the location of the stored data can be changed and stored in a file on the specified server. You need to configure django and only use ip_hash.

summary:

1、如果多台应用服务器连接的是同一台服务器上的数据库的话，使用权重，分配IP_Hash 都可以
2、如果多台应用服务器连接的是不同服务器的数据库，那么使用权重的分配方式就出问题了，那么可以使用的方式 ip_hash解决问题

END