Nginx负载均衡中对session处理分析一

最近讲解了几节关于负载均衡的文章，我们中间使用了nginx负责转发服务器，负责管理后端服务器的事情，不过有些人可能会注意到，应用服务器的session是如何处理的，我们可不可以使用nginx来管理呢？

答案当然是可以的。

在前几节的说明里面，我们分享了nginx之间的配置，已经安全相关的问题，以及使用nginx+keepalived实现负载均衡相关的问题，对于nginx里面关键的负责后端服务器转发的一个知识点没有说到，如果需要看回之前的内容，可以订阅我的头条号：一点热。

那就是upstream ，我们之前在配置单点的负载均衡曾经有过这么一段内容

#------------------Nginx后端服务器配置，这里我使用默认的轮询请求方式------------------#登陆后端服务器配置，配置规则是， ip:port，#weight，代表权重，权重越大，代表访问到改IP的服务器的几率越大。

upstream loginserver {

server 192.168.1.101:8080 weight=50;

server 192.168.1.102:8080 weight=50;

}

那么这里出现过upstream，这个upstream模块，就是实现我们后端转发的关键功能，对于什么是upstream，我这里简单的介绍一下，nginx里面是由各种模块来实现相对应的功能，它把模块分成三部分：handler、filter和load-balancers，handler是用来处理http请求并构造输出，而filter则是处理handler产生的输出，而load-balancers用来决定哪一个后端将会收到请求,而upstream模块正是实现load-balancers策略的方法。对应模块这个理解，如果玩过php+Apache+mysql网站的人就知道，Apache里面会有很多的模块加载，要实现什么功能，就需要开启那个模块。关于nginx模块的开发，大家也可以学习一下。

这里继续把nginx的upstream，说一下，nginx实现负载均衡有三种策略，

1、轮询调度算法

Round-Robin

轮询调度算法的原理，就是是把用户的请求按照顺序的轮流分配给app server，不断循环。

2、最少连接

least-connected

Nginx 会找出最少的连接的服务器出来，把用户的请求分配到该台app server.

3、IP散列算法

ip-hash

根据用户请求的IP，通过散列算法把请求分配到不同的服务器上,

我这里主要说一下IP-HASH,因为它和我们的session同步有关，这个算法的大致原理就是，根据请求的目标IP地址，作为散列键从静态分配的散列表找出对应的服务器，然后根据这台服务器的负载能力进行转发。

那么，我们这里要说的是session的问题，我们知道ip-hash是根据IP产生hash值的，那么可以理解的是，每个访客的IP是从客户端已经固定的了，当客户使用这个IP访问的时候，Nginx就直接转发到指定的app server,

upstream loginserver {

ip_hash;

server 192.168.1.101:8080 ;

server 192.168.1.102:8080;

}

假设，我客户端的ip是10.20.19.123,我访问到nginx的时候，nginx会根据ip，以10.20.19.123作为hash的键值产生hash结果，然后转发到后端服务器，假设转发到server 192.168.1.101:8080 ; 那么它下次再进行访问的时候，如果还是使用ip为10.20.19.123，依然会转发到192.168.1.101:8080，这样，我们可以理解到，每次我这样的IP进行访问的时候，得到的是同一台服务器，那么session也是同一台机器的，所以不存在不同的session的问题。

不过这样设计存在两个弊端：

1、既然我们这里说到的是IP-HASH,那么最关键的是IP地址，那么获取到客户端的IP地址是最重要的，有一个问题就是，如果我们的Nginx服务器，不是客户端最先进入的服务器，那nginx是无法得到正确的IP，所以这里要求的是nginx是最前端的服务器。

2、假如nginx上面如果还有nginx进行转发，而第二个nginx又通过不同的策略来转发，那么这样进行ip-hash是不起到作用的。

今天就讲到这里，下一节继续讲nginx 与session的相关知识，欢迎大家订阅我的头条号，欢迎大家交流与指出不足，我会慢慢改正，同时欢迎大家收藏与转发，同时也请大家请勿转载到其它地方，如果真的要转载，麻烦与我联系。我的头条号：一点热