Java for Web学习笔记（二十）：Session（4）在集群中使用Session

在集群中使用session

Sticky Sessions

在集群的情况下，可以采用保证同一个seesion都到同一个web container中处理的方式，即sticky sessions，有不同方式，例如load balance作为agent使用自己的cookie，因此可以更方便地辨识。在SSL/HTTPS的情况下，会无法获取session ID，可以将加解密放在load balance，例如NGINX，但这样就无法使用SSL Session ID作为HTTP Session ID。

支持Sticky Session的load balance有Apache HTTPD[1]和Microsoft IIS web server。如果数据量很大，可以在多个Apache HTTPD之前再部署一个轮询的load balance。

一个由4台web containers（4个tomcatinstance）组成的集群。在ApacheHTTPD中connector使用一个Tomcat概念session ID jvmroute（大抵根据session ID进行路由之意），每个tomcat instance应该在conf/server.xml中对<Connector>进行jvmroute配置，例如：<Engine name="Catalina" defaultHost="localhost" jvmRoute="tm02">。这个配置作为session ID的后缀，例如分布配置为tm01，tm02，tm03，tm04，那么有配置为tm02所产生的session ID为：AA64E92624FFEA976C4148DF5BC6BA03.tm02。前面的Apache Tomcat Connectors 根据后缀tm02，知道session归属那个tomcat instance进行处理。对于要求HTTPS，证书和编解码都放在Apache HTTPD中进行处理，可以获取SSL Session ID并转换为tomcat的HTTP Session ID。

复制session信息

Sticky Session的方式可以解决扩展性，但是不能解决可用性，如果某台tomcat坏了，那么在那台tomcat上的session就会丢失，用户可能有些数据没有保存。因此我们需要在其他tomcat上给出这个session信息复制，这样，当某天tomcat坏了，分配到其他tomcat，session也能继续有效。

配置上比较简单，在tomcat的server.xml中添加以下配置，告之需要将session复制到集群的其他机器上。

<distributable />

在session可以存储任何的数据，只受限于下面两个方面：

一、存储的数据态度，会消耗虚拟机的内存池

二、如果server采用集群的方式，需要将对象序列化（serialize，通过Serializable接口），并传播给整个集群。

因此session中存放的对象必须是Serializable，否则在复制过程中会报IllegalArgumentException的错误，此外必须通过setAttribute来触发负责。下面是一个小例子：

@SuppressWarnings("unchecked")Map<Integer, Integer> cart = (Map<Integer, Integer>)session.getAttribute("cart");if(!cart.containsKey(productId))    cart.put(productId, 0);cart.put(productId, cart.get(productId) + 1);session.setAttribute("cart", cart);  //必须要加上此句，才能将修改后的session内容复制到集群的其他机器

有一个javax.servlet.http.HttpSessionActivationListener和session的复制有关。当一个session进行准备Serialize并复制到其他机器，触发sessionWillPassivate()。当session在其他的container中deserialized时，sessionDidActivate()被触发。

最后，强调一下，Sticky sessions和session复制这两种方式不是二选一的，相反，是通常一起使用的。

---

[1] 参见：http://tomcat.apache.org/connectors-doc/

相关链接： 我的Professional Java for Web Applications相关文章