Linux企业实战-tomcat-session保持

骑猪看日落 2023-07-12 14:44 64阅读 0赞

## 1.应用服务器集群的Session管理 ##

应用服务器的高可用架构设计主要基于服务无状态这一特性，但是事实上，业务总是有状态的，在交易类的电子商务网站，需要有购物车记录用户的购买信息，用户每次购买请求都是向购物车中增加商品；在社交类的网站中，需要记录用户的当前登录状态、最新发布的消息及好友状态等，用户每次刷新页面都需要更新这些信息。  
Web应用中将这些多次请求修改使用的上下文对象称作会话（Session），单机情况下，Session可由部署在服务器上的Web容器（如JBoss）管理。在使用负载均衡的集群环境中，由于负载均衡服务器可能会将请求分发到集群任何一台应用服务器上，所以保证每次请求依然能够获得正确的Session比单机时要复杂很多。  
**（1）cookie：**  
在网站中，http请求是无状态的。也就是说即使第一次和服务器连接后并且登录成功后，第二次请求服务器依然不能知道当前请求是哪个用户。cookie的出现就是为了解决这个问题，第一次登录后服务器返回一些数据（cookie）给浏览器，然后浏览器保存在本地，当该用户发送第二次请求的时候，就会自动的把上次请求存储的cookie数据自动的携带给服务器，服务器通过浏览器携带的数据就能判断当前用户是哪个了。cookie存储的数据量有限，不同的浏览器有不同的存储大小，但一般不超过4KB。因此使用cookie只能存储一些小量的数据。

**（2）session：**  
session和cookie的作用有点类似，都是为了存储用户相关的信息。不同的是，cookie是存储在本地浏览器，而session存储在服务器。存储在服务器的数据会更加的安全，不容易被窃取。但存储在服务器也有一定的弊端，就是会占用服务器的资源，但现在服务器已经发展至今，一些session信息还是绰绰有余的。

**（3）cookie和session结合使用：**  
web开发发展至今，cookie和session的使用已经出现了一些非常成熟的方案。在如今的市场或者企业里，一般有两种存储方式：

> 1> 存储在服务端：通过cookie存储一个session id，然后具体的数据则是保存在session中。如果用户已经登录，则服务器会在cookie中保存一个session\_id，下次再次请求的时候，会把该session\_id携带上来，服务器根据session id在session库中获取用户的session数据。就能知道该用户到底是谁，以及之前保存的一些状态信息。这种专业术语叫做server side session。

> 2> 将session数据加密，然后存储在cookie中。这种专业术语叫做client side session。flask采用的就是这种方式，但是也可以替换成其他形式

## 2.交叉保存实现session保持 ##

注意：此实验是在上一篇博客的基础上做的

修改tomcat服务的发布页面：  
server2上写入：

root@server2 tomcat]# cd /usr/local/tomcat/webapps/ROOT/
    [root@server2 ROOT]# vim test.jsp 
    写入：
    <%@ page language="java" %>
    <html>
    <head><title>TomcatA</title></head>
    <body>
    <h1><font color="blue">Tomcat-server1</font></h1>
    <table align="centre" border="1">
    <tr>
            <td>Session ID</td>
            <% session.setAttribute("magedu.com","magedu.com"); %>
            <td><%= session.getId() %></td>
    </tr>
    <tr>
            <td>Created on</td>
            <td><%= session.getCreationTime() %></td>
    </tr>
    </table>
    </body>
    </html>

server3上写入：

root@server2 tomcat]# cd /usr/local/tomcat/webapps/ROOT/
    [root@server2 ROOT]# vim test.jsp 
    写入：
    <%@ page language="java" %>
    <html>
    <head><title>TomcatA</title></head>
    <body>
    <h1><font color="blue">Tomcat-server2</font></h1>
    <table align="centre" border="1">
    <tr>
            <td>Session ID</td>
            <% session.setAttribute("magedu.com","magedu.com"); %>
            <td><%= session.getId() %></td>
    </tr>
    <tr>
            <td>Created on</td>
            <td><%= session.getCreationTime() %></td>
    </tr>
    </table>
    </body>
    </html>

在客户端浏览器测试http://172.25.1.1/test.jsp：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 1]  
通过测试发现每次轮训调度session都会发生变化说明session 是无法保存的

我们利用ip\_hash对后端粘滞的功能进行保存：  
在server1:

[root@server1 conf]# vim nginx.conf
     
     20         upstream tomcat { 
     21                 ip_hash;
     22                 server 172.25.1.2:8080;
     23                 server 172.25.1.3:8080;
     24 }

重启nginx

nginx -t
    nginx -s reload

再次进行测试发现=无论怎么刷新都会在同一台服务器上session不会发生变化（即实现了利用hash规则进行session保持）:  
![在这里插入图片描述][20200309134556974.png]  
如果我们关闭server3的tomcat在进行测试时：

[root@server3 ROOT]# cd /usr/local/tomcat/
    [root@server3 tomcat]# bin/shutdown.sh 
    Using CATALINA_BASE:   /usr/local/tomcat
    Using CATALINA_HOME:   /usr/local/tomcat
    Using CATALINA_TMPDIR: /usr/local/tomcat/temp
    Using JRE_HOME:        /usr/local/java
    Using CLASSPATH:       /usr/local/tomcat/bin/bootstrap.jar:/usr/local/tomcat/bin/tomcat-juli.jar

并不能找到server3中的session，只有server2的：  
注意：这里的Tonmcat-server1指的是server2服务器，Tonmcat-server2指的是server3服务器  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 2]  
以上实验模拟了当一台tomcat服务器宕机后session就不能保存的问题

## 交叉保存的理解: ##

当出现这种情况时我们就可以使用交叉保存的机制来实现不同tomcat服务器之间session的共享：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 3]  
上图的含义是两个tomcat服务器通过memcached可以将各自的session保存在对方的服务器中，当一台tomcat服务宕掉时，另一台服务器可以在自身的存储中取得之前的session继续为客户端服务。

## 交叉保存的实现： ##

（1）复制jar包到`/usr/local/tomcat/lib/`：

server2和server3做同样的操作

[root@server2 ROOT]# cd /root/lnmp/
    [root@server2 lnmp]# cd jar/
    [root@server2 jar]# ls
    asm-3.2.jar                              memcached-session-manager-tc7-1.6.3.jar
    kryo-1.04.jar                            minlog-1.2.jar
    kryo-serializers-0.10.jar                msm-kryo-serializer-1.6.3.jar
    memcached-session-manager-1.6.3.jar      reflectasm-1.01.jar
    memcached-session-manager-tc6-1.6.3.jar  spymemcached-2.7.3.jar
    [root@server2 jar]# cp * /usr/local/tomcat/lib/
    [root@server2 jar]# cd /usr/local/tomcat/lib/

[root@server2 lib]# rm -rf memcached-session-manager-tc6-1.6.3.jar  #因为上面有两个版本的session-manager，不删会影响实验效果
    [root@server2 lib]# vim /usr/local/tomcat/conf/context.xml

（2）编辑session存储策略文件  
server2和server3做以下操作：

vim /usr/local/tomcat/conf/context.xml
    
     34 <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
     35 memcachedNodes="n1:172.25.1.2:11211,n2:172.25.1.3:11211"
     36 failoverNodes="n1"				#此处时server2的写法，server3为n2
     37 requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
     38 transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
     39 />

（3）安装并启动memcached

server2和server3做以下操作：

yum install memcached -y
    systemctl start memcached

（4）重启tomcat：

server2和server3做以下操作：

cd /usr/local/tomcat/
    bin/shutdown.sh
    bin/startup.sh

（5）测试  
在客户端浏览器测试http://172.25.1.1/test.jsp：  
![在这里插入图片描述][20200309144809752.png]  
n1，说明这个session时server2保存的，同时也说明server3取得了在自己服务器中server2保存的session信息，即实现了session的交叉存储。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200309133843116.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200309133928842.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3,size_16,color_FFFFFF,t_70
[20200309134556974.png]: https://img-blog.csdnimg.cn/20200309134556974.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200309134518353.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20200309134851244.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDE3Njc3,size_16,color_FFFFFF,t_70
[20200309144809752.png]: https://img-blog.csdnimg.cn/20200309144809752.png