使用基于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

共同讨论

评论

13 楼 jiopi 2011-10-04  

fitliving 写道

jiopi，你好。请教一个弱弱的问题，关于写入hashid 的值，这个值我能想到只能在应用中写，可是在应用中写入hashid 的值，该如何确保这个值，是按负载的均衡写入？

想查看更多详情时，文章这个链接已经失效了
如果你对这个方案该兴趣，欢迎访问
http://jiopi.group.iteye.com/group/topic/19843

你自己写负载均衡算法就可以了，当然负载均衡之间的服务器还是需要通讯的，简单的做法可以用JGroup，这样你的每台服务器都知道每台服务器上的负载，这样每台服务器都将一个新用户按照相同的负载均衡算法指定服务器就行了。

至于那个更多详情嘛，那是我的一个想法，还没有开始实现。

12 楼 fitliving 2011-10-02  

jiopi，你好。请教一个弱弱的问题，关于写入hashid 的值，这个值我能想到只能在应用中写，可是在应用中写入hashid 的值，该如何确保这个值，是按负载的均衡写入？

想查看更多详情时，文章这个链接已经失效了
如果你对这个方案该兴趣，欢迎访问
http://jiopi.group.iteye.com/group/topic/19843

11 楼 grave 2010-06-15  

是啊 用户ip都变了...你还能指望他啥

10 楼 lovit 2010-06-13  

jiopi 写道

lovit 写道

为什么不用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自然就够了

为什么要担心一个用户改变IP？？改变IP重新登录就行了。

9 楼 jiopi 2010-06-12  

lovit 写道

为什么不用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自然就够了

8 楼 lovit 2010-06-12  

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

7 楼 jiopi 2010-06-12  

thorlst 写道

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

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

error_page   504  = @backup

然后定义一个backup

location @backup (
    proxy_pass     backend;
}

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

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

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

6 楼 pejaming 2010-06-12  

thorlst 写道

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的文章里也提到了，确实这是个问题

5 楼 thorlst 2010-06-12  

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？

4 楼 elf8848 2010-06-12  

引用

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

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

3 楼 gloomyd 2010-06-11  

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

2 楼 jiopi 2010-06-10  

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

1 楼 sw1982 2010-06-10  

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