节点集群Apache+Tomcat集群之深入Session

之前一直在查找节点集群之类的问题,上午正好有机会和大家分享一下.

    上篇已将集群环境搭建好,本篇对集群道理和Session同步停止深入分析。

    Web服务器停止集群,Session的安全和同步是最大的问题,实现Session同步有很多种方案,常见的可能的方式有:

    1、客户端Cookie加密。
    用的较少,此处不胪陈。

    2Session复制。

        参与集群的每个节点的Session状态都被复制到集群中的其他所有节点上,无论何时,只要Session发生改变,Session数据都要从新被复制。TomcatJBosswas都供给了这样的功能,其中Tomcat采用集群节点广播复制,JBoss采用配对复制机制。
    长处:每个节点都复制一份Session,一个节点涌现问题时其它节点可以接替它的任务。缺点:节点间停止Session同步会占据不少系统资源,整体性能随着集群节点数的增长而急剧下降。

    3Session同享。
    将所有节点的Session放到一同停止同一管理,每个节点在未参与集群之前都有自己独立的Session体系,参与到集群以后可以让所有节点将各自的Session信息用一套雷同的机制保存到一个同一的地方停止存取,这样不管请求被分发到哪个节点都可以拜访到其它节点创建的Session

    在上一篇<<Apache+Tomcat集群之环境搭建>>中已将集群环境搭建好,并且对环境停止了开端测试,上面就以该实验环境为依托,开始摸索Tomcat集群下的Session管理。

    1、首先停止一个实验。在balancing文件夹下创建test2.jsp,其内容如下:
<%@ page contentType="text/html; charset=GBK"%>

    <%@ page import="java.util.*"%>

    <html>

    <head>

        <title>ClusterApp Test</title>

    </head>

    <body>

        <%

            out.println("Server Info=" + request.getLocalAddr() +" : " + request.getLocalPort()+"<br>");

           out.println("Session ID=" + session.getId()+"<br>");

        %>

       

        <%

            String dataName = request.getParameter("dataName");

            if (dataName !=null && dataName.length() > 0) {

            String dataValue = request.getParameter("dataValue");

            session.setAttribute(dataName, dataValue);

            }

            out.println("<b>Session列表</b><br>");

            System.out.println("Session列表");

            Enumeration e = session.getAttributeNames();

            while (e.hasMoreElements()) {

            String name = (String)e.nextElement();

                String value = session.getAttribute(name).toString();

                out.println( name + " = " + value+"<br>");

                System.out.println( name +" = " + value);

           }

        %>

     

        <formaction="test2.jsp"method="POST">

        名称:<inputtype=textsize=20name="dataName"><br/>

        :<inputtype=textsize=20name="dataValue"><br/>

    每日一道理
坚持的昨天叫立足,坚持的今天叫进取,坚持的明天叫成功。

        <inputtype=submittext="提交">

       </form>

    </body>

    </html>

    然后修改各个节点下的balancing站点的web.xml文件,添加distributable属性,该属性告诉servlet/JSP容器,编写的应用将在分布式Web容器中部署,如下所示:

    <web-app xmlns="http://java.sun.com/xml/ns/javaee"

      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

      xsi:schemaLocation="http://java.sun.com/xml/ns/javaee

                          http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"

      version="3.0"

      metadata-complete="true">

        <display-name>Tomcat Balancing</display-name>

        <distributable/>

    </web-app>

    接下来启动Apache和四个Tomcat,拜访test2.jsp,待页面回显后做如下操作:

    1)       视察Sessionid,会发明此处的SessionId比普通的id多了一个后缀名,形如:B684550D0D118DF94C41906714531714.tomcat1

    2)       一直刷新页面,会发明页面的SessionId交替发生变化,但是前缀始终不变,形如:
B684550D0D118DF94C41906714531714.tomcat1
B684550D0D118DF94C41906714531714.tomcat2
B684550D0D118DF94C41906714531714.tomcat3
B684550D0D118DF94C41906714531714.tomcat4
此说明每次的请求并非由同一个节点停止处置的

    3)       接下来验证session是不是被同步(即复制)。在页面的输入框分别输入(11)提交,(22)提交,(33)提交,视察浏览器页面和四个Tomcat的控制台,会发明每次提交后上一次的输入内容并没有被清撤除,并且每次提交停止处置的Tomcat节点并不雷同,这说明节点间的session已停止了同步复制。

    4)       最后验证某个节点失效后对用户的影响。关掉tomcat1,一直刷新页面,会发明页面中不在涌现后缀名为tomcat1sessionid,但是session信息并没有丧失。

    还没有完,停止上面实验的前提条件是worker.loadbalancer.sticky_session=0worker. loadbalancer.sticky_session_force=0,当组合情况是(1,0),(0,1)(1,1)时停止上面的实验,会是怎样的结果呢?重复上面的实验,终究我们可以得出如下的结论:
sticky_session           sticky_session_force           结论

    0                                   0                                            session无黏性,session会复制

    0                                   1                                            session无黏性,session会复制

    1                                   0                                            session有粘性(非强制)session会复制

    1                                   1                                            session有粘性(强制)session没必要再复制(此处有争议,待深入研究

    常见问题:

    1、  如果同一台机器上的节点之间session能够同步,但是不同机器间的session没法同步,可能的原因是机器间的时钟不同步,需要停止同步操作。

    2、  关于Cluster
此实验中对Cluster的配置如下:
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
其实这只是对Cluster的最简单的一种配置,该配置下tomcat使用的是all-to-all方式的session同步,这类方式只适用于小规模的集群。文章开头列举了三种session同步策略,all-to-all属于第二种,tomcat也支撑第三种,只需为Cluster配置BackupManager即可,参看http://tomcat.apache.org/tomcat-7.0-doc/cluster-howto.html

    3、  关于jvmRoute
前面实验中的sessionid由两部分组成(前缀+后缀),而其后缀名就是jvmRoute配置的名称,mod_jk需要根据这个后缀名停止请求转发:当sticky_session=1时,mod_jk根据这个后缀名来判断该会话应当始终由哪个tomcat停止处置。

     

    4、关于mod_jk。

    在上一篇中说到mod_jk和tomcat集群本身没有必然联系,它只是做请求转发,上面做一个实验:

    不启动apache,直接启动四个tomcat,在地址栏直接输入http://localhost:11080/balancing/test2.jsp 回车,页面上的sessionid=B5644757E4C8C5E5C1C6BB4557B13D16.tomcat1,然后将端口改成12080回车,页面上的sessionid=B5644757E4C8C5E5C1C6BB4557B13D16.tomcat2,发明两个sessionid的前缀雷同 ,接着测试13080和14080都会发明sessionid的前缀雷同。进一步测试,在11080端口页面下输入(1,1)提交,然后拜访12080端口会发明(1,1)会回显到页面上,信息没有丧失,说明是一个session。

    接下来进一步测试,将四个tomcat的jvmRoute的值都删掉,重复刚刚的实验会发明除了sessionid没了后缀,其它实验结果完整雷同。至此已完整验证了上一篇中的说法,jk和集群属于两个层次的货色。

    在《Professional.Apache.Tomcat6》一书中对tomcat的集群作了更详尽的介绍,感兴趣的可以参考。

文章结束给大家分享下程序员的一些笑话语录: 关于编程语言
如果 C++是一把锤子的话,那么编程就会变成大手指头。
如果你找了一百万只猴子来敲打一百万个键盘,那么会有一只猴子会敲出一 段 Java 程序,而其余的只会敲出 Perl 程序。
一阵急促的敲门声,“谁啊!”,过了 5 分钟,门外传来“Java”。
如果说 Java 很不错是因为它可以运行在所有的操作系统上,那么就可以说 肛交很不错,因为其可以使用于所有的性别上。

你可能感兴趣的:(tomcat集群)