【转 Tomcat集群session管理解决方案(关于sticky session、session replication与使用memcached缓存sess tomcatmemcachedsticky sessionnon sticky session
程序员文章站
2024-01-09 13:15:58
...
本文原文连接: 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的一部分经过压缩和加密后存放在用户的本地浏览器上！
另外*上面一片文章
http://*.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的一部分经过压缩和加密后存放在用户的本地浏览器上！
另外*上面一片文章
http://*.com/questions/10494431/sticky-and-non-sticky-sessions