前言
在我们做Nginx负载均衡的时候经常会遇到会话保持的问题，为了保证同一用户session会被分配到同一台服务器上，这时就需要会话保持，我们常用的方法有基于ip_hash的会话保持、基于cookie的会话保持。
一、基于ip_hash的会话保持
在做Nginx的负载均衡时，可以在upstream里设置ip_hash，每个请求按访问ip的hash结果分配，映射到固定某一台的服务器，当后端服务器宕机后，session会丢失，再次发起请求时，会重新固定访问另一台正常的服务器并实现会话保持。缺点就是由于同一个IP客户端都固定访问一个后端服务器，这就可能会导致负载不均衡。下面是ip_hash的会话保持格式。
这里假设后端服务器都正常运行
在Nginx代理服务器（负载均衡服务器）中配置：===========================================upstream test { ip_hash; server 10.20.151.112:80; server 10.20.151.113:80;}
至于这里为什么会返回这个结果，在我的Nginx实现负载均衡那篇博客有具体配置操作，感兴趣的可以去看看。因此不难看出，当我使用ip_hash时，实现了session保持，即客户端会固定访问112这台后端服务器（除非这台服务器宕机了），就算再次刷新页面也不会返回其他后端服务器的内容（注意：实际生产中后端服务器返回给请求客户端的内容是一样的，这里仅仅是为了做测试效果）。
假设固定访问的那台服务器宕机了
二、基于cookie的会话保持
这种方式就是将 用户的session存入cookie里，当用户分配到不同的服务器时，先判断服务器是否存在该用户的session，如果没有就先把cookie里面的sessoin存入该服务器，实现session会话保持。缺点是存入cookie有安全隐患，比如黑客可能会获取你的cookie从而获取你相关信息。使用这种方式实现会话保持保持，需要添加sticky_cookie_insert模块，与ip_hash不同之处在于，它不是基于IP来判断客户端的，而是基于cookie来判断。
添加sticky模块（我用yum方式安装的Nginx）
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
yum install -y pcre* openssl* gcc gcc-c++ make --安装编译环境wget https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng/get/08a395c66e42.zip --下载sticky模块nginx -v --查看Nginx版本，因为要下载和yum安装nginx对应版本的源码包wget http://nginx.org/download/nginx-1.18.0.tar.gzyum install -y unzip --安装解压工具unzip 08a395c66e42.zip --解压模块包mv nginx-goodies-nginx-sticky-module-ng-08a395c66e42/ nginx-sticky-module-ng/ --改名tar xzvf nginx-1.18.0.tar.gz -C /usr/local/ --解压nginx的源码包cd /usr/local/nginx-1.18.0/nginx -V --查看yum安装nginx所有模块======================================================================================./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie' --add-module=/root/nginx-sticky-module-ng======================================================================================make && make installNginx -V --再次查看Nginx模块，添加成功 |
在代理服务器（负载均衡服务器）配置
|
1
2
3
4
5
6
7
|
vim upstream.conf --在子配置文件conf.d中创建upstream.conf=====================================================================================upstream qfedu { server 192.168.198.143; server 192.168.198.145; sticky;} |
|
1
2
3
4
5
6
7
8
9
10
|
vim proxy.conf ----在子配置文件conf.d中创建proxy.conf=====================================================================================server { listen 80; server_name localhost; location / { proxy_pass http://testweb; }} |
|
1
2
|
nginx -t --检查配置文件语法是否有错nginx -s reload --重新加载配置文件 |
访问http://10.20.151.240/
总结
Nginx会话保持一般有基于ip_hash和基于cookie两种方式，尽管Nginx的会话保持可以使某个ip客户端访问固定的后端服务器，但这可能会导致负载的不均衡。采用cookie的方式进行会话保持时，需要引入第三方模块（sticky模块）才能实现。 使用sticky_cookie_insert启用会话亲缘关系，这会导致来自同一客户端的请求被传递到一组服务器的同一台服务器，这种方法可以避免上述ip_hash中来自同一局域网的客户端和前段代理导致负载失衡的情况。 使用后端服务器自身通过相关机制保持session同步，如：使用数据库、redis、memcached 等做session复制。
到此这篇关于Nginx实现会话保持的两种方式的文章就介绍到这了,更多相关Nginx 会话保持内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家！
原文链接：https://blog.csdn.net/IT_ZRS/article/details/108552363
