Tomcat(4)-集群

置顶

stevenux

于 2020-02-01 23:18:22 发布

阅读量535

点赞数

分类专栏： Tomcat Linux_service&platform 文章标签： tomcat

本文链接：https://blog.youkuaiyun.com/YouOops/article/details/104139725

版权

本文介绍了Tomcat集群的概念，包括单机部署、多机部署的架构，并深入讨论了负载均衡策略，如轮询和ip_hash。接着，文章探讨了Tomcat的Session共享问题，包括Session复制、Session Server（如使用Memcached）以及Nginx和Httpd的调度示例。文章还提到了使用MSM实现Tomcat集群Session共享到Memcached或Redis的解决方案，分析了不同Session共享模式的优缺点和适用场景。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一.Tomcat 集群介绍

在实际生产环境中，单台 Tomcat 服务器的负载能力或者说并发能力在四五百左右。大
部分情况下随着业务增长，访问量的增加(并发量不止四五百)，单台 Tomcat 服务器是
无法承受的。这时就需要将多台 Tomcat 服务器组织起来，共同分担负载。

所以在生产环境中，一部分会使用单机部署方式，这样的部署方式在比较小的公司会见
到，大部分会使用多机部署。具体的 Tomcat 部署架构有以下几种：

单台 Tomcat 服务器部署时称为单机部署
Tomcat 单独运行，直接接受用户的请求
单台 Tomcat 服务器加上 Nginx 或者 Httpd 作为反向代理
反向代理，单机运行，提供了一个 Nginx 作为反向代理，可以做到静态由 nginx
提供响应，动态 jsp 代理给 Tomcat，如 LNMT 或者 LAMT 架构
- LNMT：Linux + Nginx + MySQL + Tomcat
- LAMT：Linux + Apache（Httpd）+ MySQL + Tomcat
使用 Nginx 反向代理多台 Tomcat 服务器
前置一台 Nginx，给多台 Tomcat 实例做反向代理和负载均衡调度，Tomcat 上
部署的纯动态页面更适合
- LNMT：Linux + Nginx + MySQL + Tomcat
使用 Nginx 反向代理多台 Tomcat 服务器，在每台 Tomcat 服务器又使用 Nginx
接收请求，如 LNNMT
- LNNMT：Linux + Nginx + Nginx + MySQL + Tomcat

二.负载均衡策略

轮询
加权轮询是 upstrean 模块默认的负载均衡策略。每个请求会按时间顺序逐一
分配到不同的后端服务器。默认情况下每台服务器的权重为 1，若服务器硬件
性能差别比较大，则需要为不同的服务器分配不同的权重。

upstream serverpool{
   
   server localhost:8000;  # server指令指明后端服务器
   server localhost:9000;
   server www.suosuoli.cn weight=1 fail_timeout=5s max_fail=3;
}

server {
   
    listen 88;
    server_name localhost;
    location / {
   
        proxy_pass http://serverpool/;
    }
}

upstream 模块中的 server 指令参数说明：

参数	描述
fail_timeout	与 max_fails 结合使用
max_fails	设置在 fail_timeout 参数设置的时间内最大失败次数,如果在这个时间内，所有针对该服务器的请求都失败了,那么认为该服务器会被访为是停机了
fail_time	服务器会被认为停机的时间长度,默认为 10s
backup	标记该服务器为备用服务器。当主服务器停止时，请求会被发送到它这里
down	标记服务器永久停机了

ip_hash
指定负载均衡器按照基于客户端 IP 的分配方式,这个方法确保了相同的客户端的
请求一直发送到相同的服务器,以保证客服端和服务器的 session 会话。这样每
个访客都固定访问一个后端服务器,可以解决 session 不能跨服务器的问题。

upstream serverpool{
   
   1p_hash;
   server 192.168.192.122:8080 weight=3;
   server 192.168.192.133:8080 weight=1;
}

三.Tomcat 的 session 共享

当单机的 Tomcat，演化出多机多级部署的时候，一个问题便凸显出来，这就是
Session。而这个问题的由来，是由于 HTTP 协议在设计之初没有想到未来的发展。

HTTP 的无状态、有连接和短连接特性

无状态：指的是服务器端无法知道 2 次请求之间的联系，即使是前后 2 次请求
来自同一个浏览器，也没有任何数据能够判断出是同一个浏览器的请求。后来可
以通过 cookie、session 机制来判断。
- 浏览器端第一次通过 HTTP 请求服务器端时，在服务器端使用 session 技术，
  就可以在服务器端产生一个随机值即 SessionID 发给浏览器端，浏览器端收到
  后会保持这个 SessionID 在 Cookie 当中，这个 Cookie 值一般不能持久存
  储，浏览器关闭就消失。浏览器在每一次提交 HTTP 请求的时候会把这个
  SessionID 传给服务器端，服务器端就可以通过比对知道当前是谁访问。
- Session 通常会保存在服务器端内存中，如果没有持久化，则易丢失
- Session 会定时过期。过期后浏览器如果再访问，服务端发现没有此 ID，将给
  浏览器端重新发新的 SessionID
- 更换浏览器也将重新获得新的 SessionID
有连接：是因为 HTTP1.x 基于 TCP 协议，是面向连接的，需要 3 次握手、4 次
挥手断开。
短连接：Http 1.1 之前，都是一个请求一个连接，而 Tcp 的连接创建销毁成本高
，对服务器有很大的影响。所以，自 Http 1.1 开始，支持 keep-alive，默认也开
启，一个连接打开后，会保持一段时间（可设置），浏览器再访问该服务器就使用这
个 Tcp 连接，减轻了服务器压力，提高了效率。

如果应用需要用户进行登录，Nginx 作为反向代理服务器代理后端 Tomcat 接收请求，
那么这个时候，就会出现 Session 相关的问题。

解决这种由于反向代理服务而导致的使得同一个客户端的请求找不到自己对应的
Session 的问题可以使用 Session 共享机制。有以下几种方案：

3.1 ip_hash 策略

由一个用户发起的请求，只会被调度到特定的 TomcatA 服务器上进行处理，另一个
用户发起的请求只在 TomcatB 上进行处理。那么这个时候，同一个用户发起的请
求，都会通过 nginx 的 ip_hash 策略，将请求转发到其中的一台 Tomcat 上。

在 Nginx 的反向代理中 ip_hash 策略也叫 source ip，即源地址哈希；如果使用
HAProxy 做代理服务器，则可以使用 Cookie 来保持会话。

3.2 Session 复制集群

Session 复制的原理是通过 Tomcat 集群的内部多播机制将所有的不同 Session 在
集群的所有 Tomcat 主机上复制，即所有 Tomcat 服务器都存有当前的所有 Session
信息。

缺点

Tomcat 的同步节点不宜过多，互相即时通信同步 session 需要太多带宽
每一台都拥有全部 session，内存占用太多

3.3 Session Server

session 共享服务器，共享的 Session 服务器使用 memcached 或者 redis 做存
储，来存储 session 信息，供 Tomcat 服务器查询。

3.4 简单的 Nginx 调度和 Session 共享示例

3.4.1 示例使用环境

环境规划

IP	主机名	服务	备注
192.168.142.151	t0	调度器	Nginx、HTTPD
192.168.142.152	t1	tomcat1	JDK8、Tomcat8
192.168.142.153	t2	tomcat2	JDK8、Tomcat8

每台主机使用 hosts 文件解析 ip

192.168.142.151 t0.suosuoli.cn t0
192.168.142.152 t1.suosuoli.cn t1
192.168.142.153 t2.suosuoli.cn t2

3.4.2 Tomcat 配置

先编写测试使用的 jsp:位于 t1 和 t2 节点的/data/webapps/index.jsp

<%@ page import="java.util.*" %>
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>lbjsptest</title>
</head>
<body>
<div>On  <%=request.getServerName() %></div>
<div><%=request.getLocalAddr() + ":" + request.getLocalPort() %></div>
<div>SessionID = <span style="color:blue"><%=session.getId() %></span></div>
<%=new Date()%>
</body>
</html

t1 虚拟主机配置

<Engine name="Catalina" defaultHost="t1.suosuoli.cn">
    <Host name="t1.suosuoli.cn" appBase="/data/webapps" autoDeploy="true" />
</Engine>

t2 虚拟主机配置

<Engine name="Catalina" defaultHost="t2.suosuoli.cn">
    <Host name="t2.suosuoli.cn" appBase="/data/webapps" autoDeploy="true" />
</Engine>

每台 Tomcat 配置大同小异：

# 环境变量配置
vim /etc/profile.d/tomcat.sh
export CATALINA_HOME=/usr/local/tomcat
export PATH=$CATALINA_HOME/bin:$PATH

# 项目路径配置
mkdir -pv /data/webapps/ROOT

# 编写测试jsp文件，内容在上面
vim /data/webapps/index.jsp
scp -r server.xml 192.168.142.153:/usr/local/tomcat

# 启动Tomcat服务
 startup.sh

3.4.3 Nginx 配置

upstream backendpool {
   
        #ip_hash; # 先禁用观察轮询的sessionid变化，之后开启开session黏性
        server t1.suosuoli.cn:8080;
        server t2.suosuoli.cn:8080;
    }

    server {
   
        location ~* \.(jsp|do)$ {
   
            proxy_pass http://backendpool;
        }
    }

访问测试http://t0.suosuoli.cn/index.jsp，可以看到轮询调度效果。
在 upstream 中使用 ip_hash 指令，使用客户端 IP 地址 Hash。这个 hash
值使用 IP v4 地址的前 24 位或全部的 IP v6 地址。
配置完 reload nginx 服务。测试一下观察效果。关闭 Session 对应的 Tomcat
服务，再重启 tomcat，观察 Session 的变化。