本篇内容介绍了“Nginx会话保持的方法是什么”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
在使用负载均衡的时候会遇到会话保持的问题，常用的方法有：
1.ip hash，根据客户端的IP，将请求分配到不同的服务器上
2.cookie，服务器给客户端下发一个cookie，具有特定cookie的请求会分配给它的发布者
注意：cookie需要浏览器支持，且有时候会泄露数据
1.Sticky工作原理：
Sticky是nginx的一个模块，它是基于cookie的一种nginx的负载均衡解决方案，通过分发和识别cookie，来使同一个客户端的请求落在同一台服务器上，默认标识名为route
（a）客户端首次发起访问请求，nginx接收后，发现请求头没有cookie，则以轮询方式将请求分发给后端服务器。
（b）后端服务器处理完请求，将响应数据返回给nginx。
（c）此时nginx生成带route的cookie，返回给客户端。route的值与后端服务器对应，可能是明文，也可能是md5、sha1等Hash值
（d）客户端接收请求，并保存带route的cookie。
（e）当客户端下一次发送请求时，会带上route，nginx根据接收到的cookie中的route值，转发给对应的后端服务器。
2.重新编译nginx增加nginx-sticky-module模块
查询bitbucket.org上的该模块相关文档
https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng/overview
#查询当前的nginx编译参数可以使用以下命令：
/usr/local/nginx/sbin/nginx -V
[root@nginx ~]# mkdir -p /server/tools
[root@nginx ~]# cd /server/tools
[root@nginx tools]# /usr/local/nginx/sbin/nginx -V
nginx version: nginx/1.8.0
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx --user=nginx --group=nginx --with-http_stub_status_module --with-http_ssl_module
#下载该模块的软件包（）
#其他平台上的nginx-sticky-module模块包多是国外的资源的不方便下载，找到GITHUB上面的该软件包
[root@nginx tools]# wget https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng/get/08a395c66e42.zip
#解压
[root@nginx tools]# unzip -D nginx-goodies-nginx-sticky-module-ng-08a395c66e42.zip
[root@nginx tools]# mv nginx-goodies-nginx-sticky-module-ng-08a395c66e42 nginx-sticky-module-ng
#备份之前的nginx目录（注意：nginx日志可能很大）
[root@nginx tools]# cp -rf /usr/local/nginx/ /server/backup/
#进入到之前编译好的nginx目录下，重新进行编译安装
# 注意：是覆盖安装
[root@nginx tools]# cd nginx-1.8.0
[root@nginx nginx-1.8.0]# ./configure --prefix=/usr/local/nginx --user=nginx --group=nginx --with-http_stub_status_module --with-http_ssl_module --add-module=/server/tools/nginx-sticky-module-ng
[root@nginx nginx-1.8.0]# make
[root@nginx nginx-1.8.0]# make install
#安装完再次查看nginx编译参数
[root@nginx tools]# /usr/local/nginx/sbin/nginx -V
nginx version: nginx/1.8.0
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC)
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
configure arguments: --prefix=/usr/local/nginx --user=nginx --group=nginx --with-http_stub_status_module --with-http_ssl_module --add-module=/server/tools/nginx-sticky-module-ng
#需要重新启动nginx才可以使用sticky模块
[root@nginx tools]# service nginx restart
#编辑配置文件，实例：
upstream www_web_com {
#ip_hash;
sticky expires=1h domain=web.com path=/;
server 10.0.0.16:8080;
server 10.0.0.17:8080;
}
#具体的配置根据公司的相关业务配置即可
#之后打开网站进行测试，使用sticky的情况下，不管怎么刷新都是如下结果
#不使用Nginx sticky模块时，刷几次就变了（有时候刷一次，有时候多刷几次）
备注：每台后端真实服务器都会有一个唯一的route值,所以不管你真实服务器前端有几个装了sticky的nginx代理,他都是不会变化的.
3.sticky模块的使用
#位置：upstream标签内
upstream {
sticky;
server 127.0.0.1:9000;
server 127.0.0.1:9001;
server 127.0.0.1:9002;
}
#参数，解析
sticky [name=route] [domain=.foo.bar] [path=/] [expires=1h]
[hash=index|md5|sha1] [no_fallback] [secure] [httponly];
[name=route] 设置用来记录会话的cookie名称
[domain=.foo.bar] 设置cookie作用的域名
[path=/] 设置cookie作用的URL路径，默认根目录
[expires=1h] 设置cookie的生存期，默认不设置，浏览器关闭即失效，需要是大于1秒的值
[hash=index|md5|sha1] 设置cookie中服务器的标识是用明文还是使用md5值，默认使用md5
[no_fallback] 设置该项，当sticky的后端机器挂了以后，nginx返回502 (Bad Gateway or Proxy Error) ，而不转发到其他服务器，不建议设置
[secure] 设置启用安全的cookie，需要HTTPS支持
[httponly] 允许cookie不通过JS泄漏，没用过
4.其他的参数：语法：
以下内容摘录于：http://blog.csdn.net/yu870646595/article/details/52056340
session_sticky [cookie=name] [domain=your_domain] [path=your_path] [maxage=time][mode=insert|rewrite|prefix]
[option=indirect] [maxidle=time] [maxlife=time] [fallback=on|off] [hash=plain|md5]
mode设置cookie的模式:
insert:在回复中本模块通过Set-Cookie头直接插入相应名称的cookie。
prefix:不会生成新的cookie，但会在响应的cookie值前面加上特定的前缀，当浏览器带着这个有特定标识的cookie再次请求时，模块在传给后端服务前先删除加入的前缀，后端服务拿到的还是原来的cookie值，这些动作对后端透明。如：”Cookie: NAME=SRV~VALUE”。
rewrite: 使用服务端标识覆盖后端设置的用于session sticky的cookie。如果后端服务在响应头中没有设置该cookie，则认为该请求不需要进行session sticky，使用这种模式，后端服务可以控制哪些请求需要sesstion sticky，哪些请求不需要。
option设置用于session sticky的cookie的选项，可设置成indirect或direct。indirect不会将session sticky的cookie传送给后端服务，该cookie对后端应用完全透明。direct则与indirect相反。
maxidle设置session cookie的最长空闲的超时时间
maxlife设置session cookie的最长生存期
maxage是cookie的生存期。不设置时，浏览器或App关闭后就失效。下次启动时，又会随机分配后端服务器。所以如果希望该客户端的请求长期落在同一台后端服务器上，可以设置maxage。
hash不论是明文还是hash值，都有固定的数目。因为hash是server的标识，所以有多少个server，就有等同数量的hash值。
5.其他需要注意的
（a）同一客户端的请求，有可能落在不同的后端服务器上
如果客户端启动时同时发起多个请求。由于这些请求都没带cookie，所以服务器会随机选择后端服务器，返回不同的cookie。当这些请求中的最后一个请求返回时，客户端的cookie才会稳定下来，值以最后返回的cookie为准。
（b）cookie不一定生效
由于cookie最初由服务器端下发，如果客户端禁用cookie，则cookie不会生效。
（c）客户端可能不带cookie
Android客户端发送请求时，一般不会带上所有的cookie，需要明确指定哪些cookie会带上。如果希望用sticky做负载均衡，请对Android开发说加上cookie。
（d）cookie名称不要和业务使用的cookie重名。Sticky默认的cookie名称是route，可以改成任何值。
（e）客户端发的第一个请求是不带cookie的。服务器下发的cookie，在客户端下一次请求时才能生效。
（f）Nginx sticky模块不能与ip_hash同时使用
“Nginx会话保持的方法是什么”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注编程之家网站，小编将为大家输出更多高质量的实用文章！
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。