Nginx 连接tomcat时会话粘性问题分析及解决方法

在多台后台服务器的环境下，我们为了确保一个客户只和一台服务器通信，我们势必使用长连接。使用什么方式来实现这种连接呢，常见的有使用nginx自带的ip_hash来做，我想这绝对不是一个好的办法，如果前端是CDN，或者说一个局域网的客户同时访问服务器，导致出现服务器分配不均衡，以及不能保证每次访问都粘滞在同一台服务器。如果基于cookie会是一种什么情形，想想看, 每台电脑都会有不同的cookie，在保持长连接的同时还保证了服务器的压力均衡。

问题分析：

1. 一开始请求过来，没有带session信息，jvm_route就根据round robin的方法，发到一台tomcat上面。

2. tomcat添加上session 信息，并返回给客户。

3. 用户再此请求，jvm_route看到session中有后端服务器的名称，它就把请求转到对应的服务器上。

暂时jvm_route模块还不支持默认fair的模式。jvm_route的工作模式和fair是冲突的。对于某个特定用户，当一直为他服务的 tomcat宕机后，默认情况下它会重试max_fails的次数，如果还是失败，就重新启用round robin的方式，而这种情况下就会导致用户的session丢失。

总的说来，jvm_route是通过session_cookie这种方式来实现session粘性，将特定会话附属到特定tomcat上,从而解决session不同步问题，但无法解决宕机后会话转移问题。
假如没有这个jvm_route,用户再请求的时候，由于没有session信息，nignx就会再次随机的发送请求到后端的tomcat服务器，这种情况，对于普通的页面访问是没有问题的。对于带有登录验证信息的请求，其结果就是永远登录不了应用服务器。

这个模块通过session cookie的方式来获取session粘性。如果在cookie和url中并没有session，则这只是个简单的round-robin 负载均衡。

要解决以上类似的问题，从网上查了下，大致有如下几种方式：

1）ip_hash（不推荐使用）

 nginx中的ip_hash技术能够将某个ip的请求定向到同一台后端，这样一来这个ip下的某个客户端和某个后端就能建立起稳固的session，ip_hash是在upstream配置中定义的： 

 upstream backend {    server 192.168.12.10:8080 ;    server 192.168.12.11:9090 ;    ip_hash;    } 

不推荐使用的原因如下：

  1/ nginx不是最前端的服务器。

   ip_hash要求nginx一定是最前端的服务器，否则nginx得不到正确ip，就不能根据ip作hash。譬如使用的是squid为最前端，那么nginx取ip时只能得到squid的服务器ip地址，用这个地址来作分流是肯定错乱的。

       2/ nginx的后端还有其它方式的负载均衡。

   假如nginx后端又有其它负载均衡，将请求又通过另外的方式分流了，那么某个客户端的请求肯定不能定位到同一台session应用服务器上。