使用基于Nginx集群策略后置模式避免Session复制

前些日子大家在讨论使用Nginx负载均衡和集群，Nginx的确是一个不错的轻量级选择（http://www.iteye.com/topic/676347）

 

对Java Web容器进行集群时，Session共享是一个大问题，上文的方案使用了 Session共享的中央服务器 解决方案，即session保存在 中央服务器(memcached) 中， 这也是目前主流的解决方案

 

该类方案 在 中央服务器不宕机的情况下，可以保证session的绝对可靠，缺点是中央服务器需要绝对可靠，如果中央服务器宕机，后果可能比较严重

 

如果你可以接受，如果 集群中的一台服务器宕机，那么存储在该服务器上的Session丢失的前提，那么你可以考虑 基于Nginx集群策略后置的模式，也就是我在那篇文中提到的，基于Session key的负载均衡策略

http://www.iteye.com/topic/676347#1514234

从而无需考虑Session共享问题，因为Session有效期内，一个用户只会访问一台服务器

 

 

这个策略主要是为修正在session有效期内，保证即使客户访问IP变化，依然可以被指定到同一台服务器

 

思路是，由nginx根据某个cookie的值来判定应该定向到的服务器，而不是根据IP策略

 

具体做法如下：

upstream  backend  {   
      server   192.168.1.1:8080;   
      server   192.168.1.2:8080;   
}
server {
    listen       80;   
    location / {
        if ($cookie_hashid ~ 1) {
                proxy_pass http://192.168.1.1:8080;
        }
        if ($cookie_hashid ~ 2) {
                proxy_pass http://192.168.1.2:8080;
        }
        proxy_pass     backend;
    }
}

 

其中 hashid 是一个cookie值，你可以用任何方法将这个值设置进去

这样你便可以让nginx根据hashid的值来选择使用固定的一台服务器

当然第一次肯定没有值，nginx会采取标准负载均衡方式进行分配

 

 

这个策略的问题就是 如果 其中一台服务器宕机了，原访问该服务器的用户,nginx还会继续让他们访问，直到超时后才能做出其他处理，当然nginx非常灵活，可能有解决这个问题的办法，只是我还没找到

 

因此该策略并不适用大型网站，或希望建立高度稳定的集群环境的需求

 

 

为了建立更加灵活的 集群模式 下的Session共享机制，即 不引入 中央服务器，又可以保证Session可以在一个大型集群环境中进行高效率的共享(仅在必要时进行Session跨服务器复制)，并且所有服务器均使用完全相同的配置，从而保证集群容量的灵活变更，让新加入的服务器(新的服务器或重启后的服务器)自动纳入Session共享管理范围

 

当然，该方案的前提还是要尽可能保证让用户访问同一台服务器，而不是任意的访问集群中的任意一台服务器，从而最小化Session跨服务器复制带来的效率问题

 

如果你对这个方案该兴趣，欢迎访问

http://jiopi.group.iteye.com/group/topic/19843

共同讨论

个人比较看好这种方式，避免session同步会减少很多后续非常复杂的问题。

http://code.google.com/p/nginx-upstream-jvm-route/
刚才发现有哥们写了一个nginx的module，思路一样，不过策略是写在模块内部的，你无法修改，如果你想策略后置，可以考虑我的做法，由你的应用来控制应当访问哪台服务器

通过cookie id来定位是非常好的。
如果所有的web服务器都共用一台中央中央服务器(memcached)，这样造成了一个单点，一旦这台服务器出现故障，其他的服务器全部down掉。这样的单点在一个应用中应该越少越好。

这个思路不错啊！我以前也这么想过，所以来看看你的实现。赞一个

upstream  backend  {   
      server   192.168.1.1:8080;   
      server   192.168.1.2:8080;   
}
server {
    listen       80;   
    location / {
        if ($cookie_hashid ~ 1) {
                proxy_pass http://192.168.1.1:8080;
        }
        if ($cookie_hashid ~ 2) {
                proxy_pass http://192.168.1.2:8080;
        }
        proxy_pass     backend;
    }
}

如果一个用户$cookie_hashid为1，定位到http://192.168.1.1:8080;
然而http://192.168.1.1:8080服务当掉了， 你是怎么处理的？难道要用户清除本地cookie？

lz的文章里也提到了，确实这是个问题

配置Nginx做超时处理，如果连接失败，重新进入集群重新选择：

error_page   504  = @backup

然后定义一个backup

location @backup (
    proxy_pass     backend;
}

Nginx的负载均衡策略自然会将请求发送到没有宕机的服务器

我的方案是 策略 后置，因此你可以在服务器端写程序做判断，改写 hashid ，如果你有兴趣做了实时Session备份(比如备份到数据库)，那么你也可以通过原 hashid 恢复备份

当然那，如果准备用那个插件，因为策略不是后置的，那个模块可以保证将请求重新发到新的服务器，不过之前的Session也就都丢了

为什么不用ip_hash，ip_hash如果在upstream  内的服务器有宕机的情况，那么之前在该服务器下用户，会自动切换到其它服务器上（当然，要重新登录，因为Session丢了），就不存用清除cookie

http://www.iteye.com/topic/676347#1514234

ngnix做基于访问IP地址的分发策略 跟 session的策略不太一致，session 的 key一般是保存在cookie中，而 一个用户却可能改变IP，但cookie不变，session就应当保持


如果你要求不高，ip_hash自然就够了