`
xiangxingchina
  • 浏览: 507219 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论
阅读更多

集群对session有两种吧

1、基于request的负载均衡

    该种方式下,负载均衡器 (load balancer)会根据各个node的状况,把每个 http request进行分发。使用这样的均衡策略,就必须在多个node之间复制用户的session,实时保持整个cluster的用户状态同步,这种操作 被称为session复制(session replication)。Jboss的实现原理是使用拦截器(interceptor),根据用户的同步策略拦截request,做同步处理后再交给 server产生响应。

    该方法的优点是客户不会被绑定都具体的node,只要还有一个node存活,用户状态都不会丢失,cluster都能够继续工作。缺点是node之间通信频繁,响应速度有影响,多并发、高频操作的情况下性能下降比较厉害。

2、    基于用户的负载均衡

该 种方式下,当用户发出第一个request后,负载均衡器动态的把该用户分配到某个节点,并记录该节点的jvm路由,以后该用户的所有request都会 被绑定这个jvm路由,用户只会与该server发生交互,这种策略被称为粘性session(session sticky)。

该方法的优点是响应速度快,多个节点之间无须通信。缺点也很明显,某个node死掉以后,它负责的所有用户都会丢失session。

 

 

 

方案1,需要application server 支持,且开发时,要避免使用重型的Session来解决问题。

方案2,只需要apache来解决就可以了.

方案1 实际上需要 load-balance + session replication.

方案2 就只有load-balance了。

方案1应当是人们经常说的群集方案吧,必须要有软件支持吧。

方案2就是load-balance方案,可以基于硬件,也可以基于软件.

 

 

 

 

两个方案可以结合着来做:

前端apache使用session sticky方法保证同一用户总是导向同一个node,后端JBoss(注意不是Tomcat)配置异步session复制。

这样在通常情况下有apache保证请求可以达到hold该用户状态的node,而异步session复制有可以保证不影响性能,最后当该node fail以后,apache路由到其他node的时候,JBoss的异步复制又可以保证其他node已经拥有该用户状态。

不过对于大型的电子商务网站,apache基于HTTP协议层的load balance性能就撑不住了,这个时候可以考虑使用LVS,基于IP层协议的load balance,现在也支持session sticky(其实不需要基于session进行分发,只要基于IP进行分发就好了,用一个用户在一次session会话过程中不可能换IP的)。

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics