nginx+tomcat集群后session的处理

阅读更多

       单节点低负荷的情况下，我们通常把一个WEB应用打成WAR包放WEB应用服务器，如TOMCAT下运行就行了(如图1)。但随着用户量的增加，系统负载日益增长，这时我们通常就会采用多台WEB应用服务器组成集群来分担负荷(tomcat1, tomcat2上同时部署了应用application1; tomcat3上单独部署了应用application3)，这时某一用户对同一应用的访问就有可能分配到从不同的TOMCAT访问这个应用(如图2, session1和session2同时访问application1)。假设我们的WEB访问请求都是无状态的，多个后台应用和一个后台应用的处理就没什么区别了，根据每次请求的参数进行相关逻辑处理就行。但通常我们会将用户信息，鉴权的数据等放入session中做用户鉴权, 用户状态数据等基础框架的处理，这时我们每次分配到WEB服务器后台的访问请求就需要记录session状态及数据了，确保每次用户访问，后台从session取出的数据是一致的。

 

 

      到这里，我们已经可以清楚的看到，集群环境下，某一用户请求访问APPLICATION1，第一次请求被NGINX转发到TOMCAT1，产生了SESSION1，这时，APPLICATION1存了某一数据进SESSION1。随后，该用户进行第二次请求，这时，NGINX将该请求转发到TOMCAT2，这时TOMCAT2产生了一个新的SESSION2来访问APPLICTION1，如果这时APPLICTION1从SESSION中取刚存入的数据，因为SESSION2是TOMCAT2新产生的，并不是刚才存入数据的SESSION1，就会取不到我们想要的数据.

 

      所以，很自然的，我们就想到需要保持session1和session2的一致性。

 

      而保持session1和session2的一致性有两种很明显的方法，一种是保持session1和session2中的数据一致，二是让session1和session2成为一个session，即如果同一用户访问applcation1, tomcat1和tomcat2产生的是一个共享的session。下面就介绍下这两种处理方式.

 

1. TOMCAT间的 session复制。

 

      顾名思义，就是把一台TOMCAT上session发生变更的时候, 将变更的数据分发给其他TOMCAT。如图3

 

tomcat间是以IP组播发送变更的数据，将数据发送到集群组的其他成员。这里，同一用户访问APPLICATION1的session数据互相有了同步，他们的数据是相同的，就用app1sesson表示。

 

配置方法是配置 conf/server.xml 文件中的 Manager ，Channel，以及WEB.XML的distributable 属性。 网上已有很多配置介绍，这里就不啰嗦了。

 

2. 采用 memcached session manager 共享session。

 

       这里， tomcat1和tomcat2产生的session1和session2 在 session mananger 的管理下，都使用的是缓存中的共享session，访问应用时这样传到application1应用的session就是图中的共享session.

 

       这种共享session方案可采用google的memcached session manager, 注意下载时对应TOMCAT版本。 它以memcached作为缓存，安装时所有tomcat节点需要安装memcached-session-manager。支持sticky session 和 non-sticky session。大概原理是当一个请求结束时，session会被送回Memcached进行备份。当下一次请求开始时，本地Session可用，直接服务，请求结束后，session又被送回Memcached备份。如果下一次请求会被路由到其他Tomcat上。负责处理此此请求的Tomcat并不清楚Session的信息。此时它会从Memcached查找该Session，更新该Session并将其保存在本机内容。此次请求结束，session被修改，送回Memcached备份。如下图：

 

配置方法网上也有很多介绍，主要是修改 tomcat下 conf/server.xml, memcachedNodes可指定多个memcached节点, 逗号隔开。

 

如是非粘性，配置 sticky="false":