本文原文连接: http://blog.csdn.net/bluishglc/article/details/7641714
提要:本文主要的写作目的是解释集群方案中的一些重要的概念,然后引入另一种session管理机制:基于缓存的session管理。本文并不讲述如何配置apache和tomcat来实现集群和负载均衡,关于这方面内容,可参考我的另一篇文章:Linux下搭建tomcat集群全记录
1.实现应用服务器集群需要解决那些问题?
对于所有的应用服务器集群来说,都需要解决两个最基本也是最核心的问题:
1. 如何分散访问请求到集群的各个结点
2. 如何通过一种session管理策略,确保某一个结点失效后,其session数据能由其他结点获取以便其他结点接替失效结点,实现集群的容错(failover)
对于第一个问题,最简单最直白的想法当然是均匀散列请求到各结点,但是对于应用服务器而言,由于有session的存在,一种更好的处理方式是同一个session的相关请求分发到同一个结点进行处理,这就是所谓的“粘性ssession”(sticky session)方式的负载均衡,而前者就称之为:“非粘性ssession”(non-sticky session)方式的负载均衡.
对于第二个问题,多数的应该服务器(包括Tomcat在内)使用的是session复制(session replication)机制,即结点之间通过组播方式将各自的session发到其他所有结点上,如果其中一个访问出错,则另外结点仍然具有有效的session内容,从而能正常接管其session。由于服务器内置了session复制机制的实现,因而使用这种方案非常简单,只需要做简单的配置即可完成,但是其缺点也是很明显的,由于大量的session信息需要复制,在用户数量和集群数量达到一定规模后,session复制就有可能成为性能瓶颈。于是人们想到了别外一种解决策略:通过第三方缓存来存放sessiono数据,如果某一结点失效,被委任接替失效结点的服务器可以从缓存中恢复session.基于这种思想,在google code上有一款开源产品:memcached-session-manager。
2.memcached-session-manager的工作原理
首先,所有的tomcat节点需要安装memcached-session-manager,每一个tomcat会有自己的本地session,当一个请求执行完毕之后,如果对应的session之前不存在(也就是说这是某个用户的第一次请求),则将该session拷贝一份副本至memcached缓存,当该session的下一个请求到达时,会使用tomcat的本地session,请求处理结束之后,session的变化会同步更新到memcached缓存中对应的session里,从而确保本地session和缓存中的session始终保持一致。如果当前结点失效,下一个请求会被路由给另外一个tomcat处理,这个tomcat发现请求所属的session并不存在,于是它将查询memcached缓存,并将查询到的session恢复到本地,这样就完成了容错处理。(以上是sticky session模式为背景的解释,memcached-session-manager也支持non-sticky session。)
由于以缓存为基础的session管理不需要大量的数据复制,其性能表现更好,具有更好的伸缩性。
最后补充一点:实际上,除去有服务器端管理session,还有另一个种截然不同的管理方式,即将session作为cookie的一部分经过压缩和加密后存放在用户的本地浏览器上!
另外stackoverflow上面一片文章
http://stackoverflow.com/questions/10494431/sticky-and-non-sticky-sessions
提要:本文主要的写作目的是解释集群方案中的一些重要的概念,然后引入另一种session管理机制:基于缓存的session管理。本文并不讲述如何配置apache和tomcat来实现集群和负载均衡,关于这方面内容,可参考我的另一篇文章:Linux下搭建tomcat集群全记录
1.实现应用服务器集群需要解决那些问题?
对于所有的应用服务器集群来说,都需要解决两个最基本也是最核心的问题:
1. 如何分散访问请求到集群的各个结点
2. 如何通过一种session管理策略,确保某一个结点失效后,其session数据能由其他结点获取以便其他结点接替失效结点,实现集群的容错(failover)
对于第一个问题,最简单最直白的想法当然是均匀散列请求到各结点,但是对于应用服务器而言,由于有session的存在,一种更好的处理方式是同一个session的相关请求分发到同一个结点进行处理,这就是所谓的“粘性ssession”(sticky session)方式的负载均衡,而前者就称之为:“非粘性ssession”(non-sticky session)方式的负载均衡.
对于第二个问题,多数的应该服务器(包括Tomcat在内)使用的是session复制(session replication)机制,即结点之间通过组播方式将各自的session发到其他所有结点上,如果其中一个访问出错,则另外结点仍然具有有效的session内容,从而能正常接管其session。由于服务器内置了session复制机制的实现,因而使用这种方案非常简单,只需要做简单的配置即可完成,但是其缺点也是很明显的,由于大量的session信息需要复制,在用户数量和集群数量达到一定规模后,session复制就有可能成为性能瓶颈。于是人们想到了别外一种解决策略:通过第三方缓存来存放sessiono数据,如果某一结点失效,被委任接替失效结点的服务器可以从缓存中恢复session.基于这种思想,在google code上有一款开源产品:memcached-session-manager。
2.memcached-session-manager的工作原理
首先,所有的tomcat节点需要安装memcached-session-manager,每一个tomcat会有自己的本地session,当一个请求执行完毕之后,如果对应的session之前不存在(也就是说这是某个用户的第一次请求),则将该session拷贝一份副本至memcached缓存,当该session的下一个请求到达时,会使用tomcat的本地session,请求处理结束之后,session的变化会同步更新到memcached缓存中对应的session里,从而确保本地session和缓存中的session始终保持一致。如果当前结点失效,下一个请求会被路由给另外一个tomcat处理,这个tomcat发现请求所属的session并不存在,于是它将查询memcached缓存,并将查询到的session恢复到本地,这样就完成了容错处理。(以上是sticky session模式为背景的解释,memcached-session-manager也支持non-sticky session。)
由于以缓存为基础的session管理不需要大量的数据复制,其性能表现更好,具有更好的伸缩性。
最后补充一点:实际上,除去有服务器端管理session,还有另一个种截然不同的管理方式,即将session作为cookie的一部分经过压缩和加密后存放在用户的本地浏览器上!
另外stackoverflow上面一片文章
http://stackoverflow.com/questions/10494431/sticky-and-non-sticky-sessions