多个虚拟机Tomcat实现高效协同与负载均衡的核心方法，是把所有节点改造成无状态应用，由Nginx统一做流量分发，Session集中存放，配置和发布走同一条自动化链路。这是业内验证过的成熟做法,也是今天这篇文章要跟你拆透的主线。
多台虚拟机Tomcat负载均衡怎么做
先讲一个常见场景：你手上有两台虚拟机，都装了Tomcat，测试时单机访问一切正常，流量一上来，你会发现第一台CPU跑满，第二台几乎闲置，用户访问一会快一会慢，甚至直接超时，问题不在Tomcat本身,而在流量没有合理分到两台机器上。
负载均衡解决的就是“谁该接这个请求”的分配问题，Nginx是当前最常用的分发层，配置简单，性能好,运维也熟悉。
分配策略按业务需要分三种：
- 轮询：请求轮流分发到每台Tomcat，适合所有节点配置接近、处理能力一致的情况。
- 加权轮询：给性能更好的虚拟机配更高权重，让能力强得多干活,适合节点硬件配置有差异的环境。
- IP哈希：按用户IP计算落到固定节点，保持连接稳定，适合不需要共享Session、但希望用户一直访问同一台机器的业务。
多数场景下，策略一个重要原则是：先让Tomcat无状态，再谈轮询，只要Session存在本地，无论轮询还是哈希，都会遇到“登录后请求被分到另一台机器，用户状态丢失”的尴尬，所以先把应用里的Session迁移出去,下面会细讲方案。
多台虚拟机Tomcat负载均衡配置教程
配负载均衡前，先把你手头资源列清楚：Nginx放在哪台机器，后端Tomcat有几台，分别监听什么端口,以常用的两台Tomcat加一台Nginx为例。
第一步：写Nginx上游配置
在Nginx的/etc/nginx/conf.d/目录下新建文件tomcat_lb.conf,写入：
upstream tomcat_cluster { server 192.168.1.10:8080 weight=1 max_fails=2 fail_timeout=10s; server 192.168.1.11:8080 weight=1 max_fails=2 fail_timeout=10s; } server { listen 80; server_name yourdomain.com; location / { proxy_pass http://tomcat_cluster; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }
weight=1表示两台权重一致。max_fails和fail_timeout是健康检查的雏形，连续失败两次就把节点临时摘除,10秒后再试探恢复。
第二步：检查Tomcat实例端口
多台Tomcat跑在同一台虚拟机上时尤其注意端口冲突，编辑conf/server.xml,关注三个端口：
shutdown端口：仅本机管理用,各实例必须不同。- HTTP连接端口：默认8080，第二个实例改用8081、8082。
- AJP端口：不用就直接注释掉,避免占用和暴露不必要的协议。
如果你用的是单台虚拟机多实例，建议用CATALINA_BASE区分实例目录，各自保留独立的conf和logs,不要共用一套配置。
第三步：验证连通性
配置改完,先测Nginx语法：
nginx -t确认无报错后重新加载：
nginx -s reload再用curl分别请求Tomcat节点和Nginx入口,观察返回是否正常：
curl http://192.168.1.10:8080
curl http://192.168.1.11:8080
curl http://yourdomain.com负载均衡配置完成后怎么验证
配置生效不等于负载均衡工作正常，实际操作中,打开Nginx的访问日志：
tail -f /var/log/nginx/access.log然后从外部连续发起多个请求，理想状态是日志里的upstream地址轮番出现两台Tomcat的IP，如果长期只有一台有流量，请检查upstream里节点是否被标记为不可用,或者主机防火墙拒绝了对应端口。
多节点Tomcat健康检查如何配置
只配upstream远远不够，节点宕机、应用假死、网络抖动，这些问题光靠Nginx默认的被动检查是慢半拍的，更稳妥起见，在Nginx里加上主动健康检查模块，或引入第三方工具，即便没有额外模块，至少把max_fails调小，fail_timeout调短,让故障节点更快被摘除。
Tomcat集群Session共享方案怎么选
Session是负载均衡绕不开的话题，行业共识认为,Session留在本地就是给集群埋雷。
先对比三种主流方案：
| 方案 | 部署成本 | 首次访问体验 | 节点故障影响 | 适配场景 |
|---|---|---|---|---|
| Session Sticky（粘性会话） | 低，改Nginx配置即可 | 用户始终访问同一节点，无感 | 节点故障后该节点上的用户Session全丢 | 临时应急、单机业务改造为集群的过渡阶段 |
| Memcached/Session Cache | 中，需额外部署缓存集群 | 需反序列化，稍慢 | 缓存节点故障时Session短暂丢失 | 中小规模，Tomcat节点较多 |
| Redis统一存储 | 中高，需运维Redis | 首次访问稍慢，后续稳定 | Redis高可用做好后基本无影响 | 大部分生产环境推荐方案 |
推荐Redis方案，原因很直接：业务数据迟早要进缓存，Redis顺手把Session管起来，比单独维护一套Session Cache要省心得多。
实现方式上，老做法是在Tomcat的context.xml里配置Manager，把Session持久化到Redis，维护成本偏高，近年来更流行的是在应用代码层接管Session，比如用Spring Session替换容器默认Session管理，应用移除了对Tomcat内存的依赖，集群的任何一个节点都可以随时上下线,体验更接近云原生思路。
多机器Tomcat集群高可用方案除了负载均衡还要注意什么
很多团队配完Nginx就觉得高可用已经落地,其实这只看似精妙的架构只解决了一半问题。
业内专家指出，节点越多，由配置和应用发布引发的事故占比越高，负载均衡只管流量分发,管不了节点上的代码版本是否一致。
多节点高可用方案的完整拼图应该包括下面四块：
- 健康检查：Nginx做被动摘除，额外手段做主动检测，脚本定期探测各节点健康URL,非200直接摘除。
- 限流与降级：流量瞬间暴涨时，靠Tomcat自身线程池硬扛风险极大，网关或者Nginx
limit_req模块先挡一道,比后端崩溃再抢救有效。 - 配置与发布同步：两台Tomcat代码必须一致，把发布产物做成版本化目录，通过软链切换版本；配置文件单独管理，不随应用包漂移，统计下来,发布口径不一致是多节点集群故障的第一大来源。
- 日志集中：节点分散后，逐台翻日志是最低效的排查方式，用Filebeat采集到Elasticsearch,或者至少统一转发到同一台日志服务器。
配置同步的落地姿势
脚本化发布比手工操作靠谱得多，每次上线流程固定为：先推送代码包到每台机器，再分别执行停服、替换软链、启动、健康探测，整个流程用Ansible或Shell脚本串起来，任何人执行结果一致，没有自动化条件的，哪怕手工操作,也要保证发布顺序和校验步骤固定。
网关层限流参数怎么设才合理
限流阈值没有“标准答案”，只能根据压测结果动态调整，初次配置时，建议先压测出单台Tomcat稳定支撑的QPS，再按节点数总和打个折扣作为Nginx层的流量上限，超过阈值返回友好提示,好过让Tomcat在过载边缘反复熔断。
回到最初的问题，多个虚拟机Tomcat实现高效协同的路子一点也不神秘：无状态、统一分发、集中存储、自动化发布，如果手上已有几台闲置虚拟机，现在就按这个顺序逐步改造,比反复调优单个Tomcat参数有用得多。
多虚拟机Tomcat负载均衡配置实操常见问题排查
Tomcat负载均衡不生效怎么办
先确认三件事：
- Nginx配置是否真正加载。
nginx -t通过不代表reload成功,检查nginx进程启动时间。 - Session是否还在本地，如果应用往各自Tomcat的
work目录写Session，负载均衡越均衡,用户越容易掉线。 - 节点间时钟是否同步，Nginx和后端Tomcat时间差过大时,部分安全策略会直接拒绝转发请求。
按这个顺序排查，多数问题几分钟内能定位，最后一类情况往往是应用自身代码里持有本地缓存或定时任务,导致每台Tomcat行为不一致。
发布新代码后，部分请求总是打到旧版本，怎么办
只要Tomcat没有重启，应用类文件就被JVM锁定，新代码替换不生效，发布流程里，替换应用包后必须强制重启对应的Tomcat实例，同时保证所有节点从同一个版本仓库拉取代码，发布前比对版本号，不一致的节点不下线不接收流量，配置文件的变更也应走版本管理,让每台虚拟机的运行环境可重现。
最终排查顺序取决于你的Nginx配置是否加载成功、上游节点能否正常返回HTTP状态码，以及Session是否被应用自身接管，这三个层面逐一确认,多虚拟机Tomcat集群的稳定性就有基本保障。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/623755.html
