1200字范文 > nginx负载均衡session共享

nginx负载均衡session共享

时间：2019-10-13 06:26:54

相关推荐

nginx负载均衡session共享

文章目录

一、可道云项目结合redis缓存部署redis缓存可道云项目数据及会话，加快网站访问速度二、Nginx负载均衡会话共享1.1 什么是会话保持1.2 为什么需要会话保持1.3 Cookie机制、Session机制、token机制1.4 如何实现会话保持1.5 会话保持场景实践三、后端节点异常容错机制3.1 配置语法3.2 场景示例四、Nginx负载均衡调度场景4.1 根据uri进行调度(路由)4.2 Proxy添加/与不添加/4.3 根据请求设备进行调度五、 Nginx多级代理获取真实IP5.1 多级代理获取地址概述5.2 多级代理获取地址实践5.1 多级代理获取地址概述5.2.1.环境准备5.2.2 配置一级代理5.2.3 配置二级代理5.2.4 配置三级代理5.2.5 配置webserver5.2.5 浏览器访问，观察并分析各节点日志5.3 RealiP模块获取真实IP

一、可道云项目结合redis缓存部署

redis缓存可道云项目数据及会话，加快网站访问速度

环境准备：

1.下载可道云开源代码，部署在web01服务器上。

可道云官网下载

下载源码，解压到指定目录，授权。

[root@web01 ~]# wget wget /update/download/kodbox.1.22.zip[root@web01 ~]# mkdir /code/kedaoyun -p[root@web01 ~]# unzip kodbox.1.22.zip -d /code/kedaoyun[root@web01 ~]# chmod -R www.www /code/kedaoyun

2.编写配置文件

[root@web01 conf.d]# cat kedaoyun.conf server {listen 80;server_name ;root /code/kedaoyun;location / {index index.php;}location ~ .*\.php$ {fastcgi_pass 127.0.0.1:9000;fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;include fastcgi_params;}}

3.mysql数据库授权远程登录,确保db01开启了远程连接用户。

MariaDB [(none)]> grant all privileges on *.* to 'app'@'172.16.1.%' identified by '123kod456';

4.db01上创建可道云数据库

MariaDB [(none)]> create database kodbox;Query OK, 1 row affected (0.00 sec)

5.配置hosts文件，浏览器访问

6. redis服务器上安装redis并启用

[root@redis01 ~]# yum install redis -y

7.配置 redis 监听在本地的内网网卡上

[root@redis01 ~]# sed -i '/^bind/c bind 127.0.0.1 172.16.1.41' /etc/redis.conf

8.启动redis

[root@redis01 ~]# systemctl start redis[root@redis01 ~]# systemctl enable redis[root@redis01 ~]# netstat -ntlpActive Internet connections (only servers)Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 00 172.16.1.41:6379 0.0.0.0:*LISTEN1262/redis-server 1 tcp 00 127.0.0.1:63790.0.0.0:*LISTEN1262/redis-server 1

9.接入redis

10.查看redis已经有用户的数据了

127.0.0.1:6379> keys *1) "ac3e2_UserModel_getInfoFull_ID_1"2) "43abe268181757bedee0e410ac6c5e4b"3) "ac3e2_SystemOption_System.storageList"4) "ac3e2_SystemOption_System.sourceAuthList"5) "ac3e2_UserModel_getInfoSimple_ID_1"6) "ac3e2_SystemOption_System.noticeList"7) "ac3e2_UserTagSourceModel_listData_ID_0"

二、Nginx负载均衡会话共享

1.1 什么是会话保持

会话（Session）跟踪是Web程序中常用的技术，用来跟踪用户的整个会话。常用的会话跟踪技术是Cookie与Session。Cookie通过在客户端记录信息确定用户身份，Session通过在服务器端记录信息确定用户身份。当用户登陆一个网站服务器，网站服务器会将用户的登陆信息存储下来（存储下来的内容叫 Session ）以保证我们能够一直处于 ”登陆在线“ 状态。

1.2 为什么需要会话保持

由于我们使用的是负载均衡轮询机制，会导致用户请求分散在不同的节点，从而造成会话无法保持。假设用户A，通过负载均衡登陆了网站，此时会话信息存储在A节点，那么当它一刷新，负载均衡会将请求分发给B节点，那么B节点没有用户A的登陆信息，就会提示用户A登陆，当A用户点击登陆时又会将请求分发给C节点，从而造成用户A无法实现会话保持。

1.3 Cookie机制、Session机制、token机制

请参考：

Cookie与Session

彻底理解cookie，session，token的区别

cookie保存在客户端，但是不安全。session存在服务器端，由服务器保存，但是会增加服务器压力，而且负载均衡机制会调度在不同节点。token是结合了两者的优势。

1.4 如何实现会话保持

粘性session：指Ngnix每次都将同一用户的所有请求转发至同一台服务器上，及Nginx的 IP_hash。session复制（几乎不用）：每次session发生变化，就广播给集群中的服务器，使所有的服务器上的session相同。session共享：缓存session至内存数据库中，使用redis，memcached实现。（可以设置过期时间，过期自动清理）session持久化：将session存储至数据库中，像操作数据一样操作session。（会导致数据库大量脏数据，几乎不用）

1.5 会话保持场景实践

环境准备：

1.下载下载phpmyadmin项目

官网

2.解压到指定目录制作软连接，授权

[root@web01 ~]# unzip phpMyAdmin-5.1.1-all-languages.zip -d /code # 解压[root@web01 ~]# cd /code/[root@web01 code]# ln -s phpMyAdmin-5.1.1-all-languages/ phpmyadmin # 制作软连接[root@web01 code]# lllrwxrwxrwx 1 root root 31 Aug 18 19:57 phpmyadmin -> phpMyAdmin-5.1.1-all-languages/[root@web01 code]# chown -R www.www phpmyadmin/ # 授权

3.修改 phpmyadmin 连接远程的数据库

[root@web01 code]# cd phpmyadmin/[root@web01 phpmyadmin]# cp config.sample.inc.php config.inc.php # 修改样本名，然后修改内容[root@web01 phpmyadmin]# vim config.inc.php$cfg['Servers'][$i]['host'] = '172.16.1.51';

4编写nginx配置文件

[root@web01 conf.d]# cat phpmyadmin.conf server {listen 80;server_name ;root /code/phpmyadmin;location / {index index.php index.htmp;}location ~ .*\.php$ {fastcgi_pass 127.0.0.1:9000;fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;include fastcgi_params;} }[root@web01 conf.d]# nginx -t[root@web01 conf.d]# systemctl reload nginx

5.db01端授权远程用户登录

MariaDB [(none)]> grant all privileges on *.* to 'app'@'172.16.1.%' identified by '123guest456';Query OK, 0 rows affected (0.00 sec)

7.浏览器测试是否连接成功

8.web02节点同样的部署

9.编写负载均衡nginx配置文件

编写一份 proxy 负载均衡的配置文件，将请求调度到后端 web 节点

[root@lb01 conf.d]# cat lb_phpmyadmin.conf upstream lb_phpmyadmin {server 172.16.1.7:80;server 172.16.1.8:80;}server {listen 80;server_name ;location / {proxy_pass http://lb_phpmyadmin;include proxy_params;}}[root@lb01 conf.d]# nginx -t[root@lb01 conf.d]# nginx -t

其中proxy_params配置如下

[root@lb01 nginx]# cat proxy_params # ipproxy_set_header Host $http_host;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;# http versionproxy_http_version 1.1;proxy_set_header Connection "";# timeoutproxy_connect_timeout 120s;proxy_read_timeout 120s;proxy_send_timeout 120s;# bufferproxy_buffering on;proxy_buffer_size 8k;proxy_buffers 8 8k;

为什么要接入redis，是因为需要共享session 。否则负载均衡时候，客户第一次请求后端，服务器下发的session与第二次请求携带给后端的cookie总是不能在同一主机，所以导致永远都登录不上。解决方案有多种，可以用ip_hash、 url_hash、（缺点是只能调度到某一个节点，请求数据倾斜）。如果想调度到任意节点都不影想会话不掉线，建议使用 redis的session共享方案。

10.redis01服务器上安装redis并启用

[root@redis01 ~]# yum install redis -y

11.配置 redis 监听在本地的内网网卡上

[root@redis01 ~]# sed -i '/^bind/c bind 127.0.0.1 172.16.1.41' /etc/redis.conf

12.启动redis

13.配置php连接Redis

1.修改 /etc/php.ini 文件。[所有节点都需要操作]

[root@web01 conf.d]# vim /etc/php.inisession.save_handler = redissession.save_path = "tcp://172.16.1.41:6379";session.save_path = "tcp://172.16.1.41:6379?auth=123456" #如果redis存在密码，则使用该方式

2.注释 php-fpm.d/www.conf 里面的两条内容，否则 session 内容会一直写入 /var/lib/php/session 目录中，从而造成会话共享失败。(所有节点都需要操作)

[root@web01 conf.d]# vim /etc/php-fpm.d/www.conf ;php_value[session.save_handler] = files;php_value[session.save_path] = /var/lib/php/session

3.重启 php-fpm 服务。(所有节点都需要操作)

[root@web01 conf.d]# php-fpm -t[root@web01 conf.d]# systemctl restart nginx

14.测试集群会话共享

1.浏览器查看请求响应的cookie信息

2检查 redis 中是否存在 cookie 对应的 session 信息

[root@redis01 ~]# redis-cli127.0.0.1:6379> 127.0.0.1:6379> keys *1) "PHPREDIS_SESSION:b7681e67c147e7ce1e296a5b650b9b4d"127.0.0.1:6379>

3.此时用户的 cookie 始终都不会发生任何变化，无论请求被负载调度到那一台后端web 节点服务器都不会出现没有登陆情况。

三、后端节点异常容错机制

使用nginx负载均衡时，如何将后端请求超时的服务器流量平滑的切换到另一台上？如果后台服务连接超时，Nginx是本身是有机制的，如果出现一个节点down掉的时候，Nginx会更据你具体负载均衡的设置，将请求转移到其他的节点上，但是，如果后台服务连接没有down掉，而是返回了错误异常码如:504、502、500，该怎么办？

3.1 配置语法

3.2 场景示例

blog项目为例，如果有一个节点php-fpm服务异常停止，这样前端用户请求页面就会时而502时而正常，用户体验度极差。

解决方案：

[root@lb01 conf.d]# cat proxy_blog.conf upstream blog {server 172.16.1.7:80;server 172.16.1.8:80;}server {listen 80;server_name ;location / {proxy_pass http://blog;proxy_next_upstream error timeout http_500 http_502 http_503 http_504;proxy_next_upstream_tries 2; # 尝试的次数proxy_next_upstream_timeout 3s; # 尝试的超时时间include /etc/nginx/proxy_params;}}

四、Nginx负载均衡调度场景

4.1 根据uri进行调度(路由)

由于资源有限，每个集群其实是一台主机，基于开放多端口模拟集群中的多台主机。

web01配置如下：

[root@web01 conf.d]# cat uri.conf server {listen 8081;server_name ;root /code/user1;location / {index index.html;}}server {listen 8082;server_name ;root /code/user2;location / {index index.html;}}[root@web01 conf.d]# mkdir /code/user1[root@web01 conf.d]# mkdir /code/user2[root@web01 conf.d]# echo 'user-8081' > /code/user1/index.html[root@web01 conf.d]# echo 'user-8082' > /code/user2/index.html[root@web01 conf.d]# nginx -t[root@web01 conf.d]# systemctl reload nginx

web02配置如下：

[root@web02 conf.d]# cat uri.conf server {listen 8081;server_name ;root /code/pass1;location / {index index.html;}}server {listen 8082;server_name ;root /code/pass2;location / {index index.html;}}[root@web02 conf.d]# mkdir /code/pass1[root@web02 conf.d]# mkdir /code/pass2[root@web02 conf.d]# echo 'pass-8081' > /code/pass1/index.html[root@web02 conf.d]# echo 'pass-8082' > /code/pass2/index.html[root@web02 conf.d]# nginx -t[root@web02 conf.d]# systemctl reload nginx

lb01负载均衡配置如下：

[root@lb01 conf.d]# cat lb_uri.conf upstream user {server 172.16.1.7:8081;server 172.16.1.7:8082;}upstream pass {server 172.16.1.8:8081;server 172.16.1.8:8082;}server {listen 80;server_name ;location /user {proxy_pass http://user;include proxy_params;}location /pass {proxy_pass http://pass;include proxy_params;}}[root@lb01 conf.d]# nginx -t[root@lb01 conf.d]# systemctl reload nginx

前端修改完hosts文件后访问/user 或/pass，都会报404错误。打开任意一个节点的错误日志发现：

/08/19 00:22:01 [error] 2804#2804: *198 open() "/code/user1/user" failed (2: No such file or directory), client: 172.16.1.5, server: , request: "GET /user HTTP/1.1", host: ""

TMD 竟然路径成了 /code/user1/user ，这是为什么？

4.2 Proxy添加/与不添加/

在使用proxy_pass反向代理时，最后结尾添加/和不添加/有什么区别?

proxy_pass http://localhost:8080;proxy_pass http://localhost:8080/;

不添加时#用户请求URL： /user/index.html#请求到达Nginx负载均衡： /user/index.html#Nginx负载均衡到后端节点： /user/index.html添加/时#用户请求URL： /user/index.html#请求到达Nginx负载均衡： /user/index.html#Nginx负载均衡到后端节点： /index.html

1.带 / 意味着Nginx代理会修改用户请求的URL，将location匹配的URL进行删除。

2.不带 / 意味着Nginx代理不会修改用户请求的URL，而是直接代理到后端应用服务器

上述问题只需要在prox_pass后面加/,代码如下：

[root@lb01 conf.d]# cat lb_uri.conf upstream user {server 172.16.1.7:8081;server 172.16.1.7:8082;}upstream pass {server 172.16.1.8:8081;server 172.16.1.8:8082;}server {listen 80;server_name ;location /user {proxy_pass http://user/;include proxy_params;}location /pass {proxy_pass http://pass/;include proxy_params;}}

方案二，创建/code/user1/user 目录，将/code/user1/index.htm 移动到code/user1/user/index.html ,其他节点同理。

4.3 根据请求设备进行调度

[root@lb01 conf.d]# cat agent.conf upstream phone {server 172.16.1.7:80;}upstream pc {server 172.16.1.8:80;}server {listen 80;charset utf-8;include proxy_params;default_type text/html;server_name ;location / {if ($http_user_agent ~* 'android|iphone|ipad') {proxy_pass http://phone;}if ($http_user_agent ~* 'MSIE|Trident') {return 200 "浏览器真棒！";}proxy_pass http://pc;}}

[root@web02 conf.d]# cat pc.conf server {listen 80;server_name ;root /code/pc;location / {index index.html;}}

server {listen 80;server_name ;root /code/phone;location / {index index.html;}}

五、 Nginx多级代理获取真实IP

5.1 多级代理获取地址概述

用户发起请求，沿途可能会经过多级代理，最终抵达应用节点，那应用节点如何获取客户端真实IP地址

1：通过X-Forwarded-For透传客户端的真实IP实现方式

2：使用Nginx RealIP模块实现客户端地址透传

5.2 多级代理获取地址实践

5.1 多级代理获取地址概述

用户发起请求，经过多级代理之后， web服务器无法直接获取到客户端真实的IP地址。

$remote_addr获取的是上级反反向代理的IP地址。反向代理服务器在转发请求的http头信息中，

增加http_x_forwarded_for信息，用来记录客户端IP地址和客户端请求的服务器地址的详细过程。

5.2.1.环境准备

一级代理 10.0.0.5 proxy_node1二级代理 10.0.0.7 proxy_node2三级代理 10.0.0.9 proxy_node3真实节点 10.0.0.8 webserver路径：10.0.0.1--->10.0.0.5----->10.0.0.9------>10.0.0.8

5.2.2 配置一级代理

[root@lproxy_node1 conf.d]# cat proxy_node1.conf server {listen 80;server_name ;location / {proxy_pass http://10.0.0.7:80;proxy_http_version 1.1;proxy_set_header Connection "";proxy_set_header Host $http_host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;}}

5.2.3 配置二级代理

[root@proxy_node2 conf.d]# cat proxy_node2.conf server {listen 80;server_name ;location / {proxy_pass http://10.0.0.9:80;proxy_http_version 1.1;proxy_set_header Connection "";proxy_set_header Host $http_host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;}}

5.2.4 配置三级代理

[root@proxy_node3 conf.d]# cat proxy_node3.conf server {listen 80;server_name ;location / {proxy_pass http://10.0.0.8:80;proxy_http_version 1.1;proxy_set_header Connection "";proxy_set_header Host $http_host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;}}

5.2.5 配置webserver

web02.conf web.conf [root@weberver conf.d]# cat web.conf server {listen 80;server_name ;root /code/ip;location / {index index.html;}}

5.2.5 浏览器访问，观察并分析各节点日志

以下是各级代理的访问日志信息，请注意观察第一段$remote_addr和最后一段$http_x_forwarded_for的信息。

# 一级代理日志10.0.0.1 - - [20/Aug/:00:24:12 +0800] "GET / HTTP/1.1" 200 11 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36" "-"# 二级代理日志10.0.0.5 - - [20/Aug/:00:24:12 +0800] "GET / HTTP/1.1" 200 11 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36" "10.0.0.1"# 三级代理日志172.16.1.7 - - [20/Aug/:00:24:12 +0800] "GET / HTTP/1.1" 200 11 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36" "10.0.0.1, 10.0.0.5"# webserver日志10.0.0.9 - - [20/Aug/:00:24:12 +0800] "GET / HTTP/1.1" 200 11 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36" "10.0.0.1, 10.0.0.5, 10.0.0.7"

5.3 RealiP模块获取真实IP

使用nginx Realip_module获取多级代理下的客户端真实IP地址,在后端Web节点上添加如下配置即可（Realip需要知道所有沿途经过的代理节点的IP地址或IP段）；

[root@web02 conf.d]# cat web.conf server {listen 80;server_name ;set_real_ip_from 10.0.0.5;set_real_ip_from 10.0.0.7;set_real_ip_from 10.0.0.9;real_ip_header X-Forwarded-For;real_ip_recursive on;root /code/ip;location / {index index.html;}}#set_real_ip_from：真实服务器上一级代理的IP地址或者IP段,可以写多行 #real_ip_header：从哪个header头检索出需要的IP地址 #real_ip_recursive：递归排除set_real_ip_from里面出现的IP,其余没有出现的认为是用户真实IP

再次查看日志：

# 一级代理日志10.0.0.1 - - [20/Aug/:01:06:39 +0800] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36" "-"# 二级代理日志10.0.0.5 - - [20/Aug/:01:06:39 +0800] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36" "10.0.0.1"# 三级代理日志10.0.0.7 - - [20/Aug/:01:06:39 +0800] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36" "10.0.0.1, 10.0.0.5"# webserver日志10.0.0.1 - - [20/Aug/:01:06:39 +0800] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36" "10.0.0.1, 10.0.0.5, 10.0.0.7"

可以看到，最终结果是

10.0.0.1 - - [20/Aug/:01:06:39 +0800] "GET / HTTP/1.1" 304 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36" "10.0.0.1, 10.0.0.5, 10.0.0.7"

而10.0.0.5、10.0.0.7、10.0.0.9都出现在出现在set_real_ip_from中，仅仅10.0.0.1没出现，那么他就被认为是用户真实的ip地址，同时会被赋值到$remote_addr变量中，这样我们的程序无需做任何修改，直接使用$remote_addr变量即可获取真实IP地址。

本内容不代表本网观点和政治立场，如有侵犯你的权益请联系我们处理。

网友评论

网友评论仅供其表达个人看法，并不表明网站立场。