mod_jk--session
1 :true;0:false
tomcat session
tomcat集群方式
1. 负载平衡:
2. 状态复制(集群):先进行负载平衡,再在各服务器间复制应用状态。
一种是把所有Session数据放到一台服务器上或者数据库中,集群中的所有节点通过访问这台Session服务器来获取数据;
另一种就是在集群中的所有节点间进行Session数据的同步拷贝,任何一个节点均保存了所有的Session数据。
对于tomcat的集群有两种方式,这个主要是针对session而言的。
一种就是sticky模式,即黏性会话模式。所谓sticky模式就是说同一个用户的访问请求都被派送到同一个tomcat实例上,这样我们就无须在多台服务器之间实现session共享了,这是其好处,不好的地方就是不能实现failureover了,一但用户访问的机器挂掉,那么其session就会丢失。
另外一种就是session复制模式了。session复制模式就可以很好的解决failureover的问题,即使某一台web服务器挂掉了,用户的请求还会被负载到其他的web服务器上,而且session也被复制了,这样对用户而言就像是在同一台机器上操作一样,不好的地方就是session复制需要系统资源和网络的开销,尤其是当web服务器多的时候或session里存储的数据量大的时候,这点将会比较的明显(不过自己还没有做这方面的测试)。
针对这两种方式的弊端和好处,我们可以采用将两种方式结合的方式来达到更好的效果,那就是sticky+session复制模式了。用户的请求按照sticky方式被分发到同一个web服务器上,同时tomcat在后台做异步复制(非同步)session到其他web服务器,这样我们使用sticky的简便性,同时又有了一定的容错能力。
session复制配置
tomcat集群中的session管理,主要有两种方式:
1).粘性session
表示从同一窗口发来的请求都将有集群中的同一个tomcat进行处理。配置方式是在上面workers.properties文件中
Xml代码
worker.lbcontroller.sticky_session=True
worker.lbcontroller.sticky_session=True 粘性session的好处在不会在不同的tomcat上来回跳动处理请求,但是坏处是如果处理该session的tomcat崩溃,那么之后的请求将由其他tomcat处理,原有session失效而重新新建一个新的session,这样如果继续从session取值,会抛出nullpointer的访问异常。
2).session复制
session复制是指tomcat彼此之间通过组播方式将session发到各个tomcat实例上,如果其中一个访问出错,则另外tomcat仍然具有有效的session内容,从而能正常接管其session。坏处是当tomcat实例很多,或者用户在session中有大量操作时,组播发送的信息量十分惊人。session复制配置则是在发布的web应用程序中的web.xml中添加
Xml代码
<distributable/>
<distributable/> 此外,session复制所需的JDK必须是JDK 5.0及其以上版本。