核心是两步:tomcat多实例需修改8005、8080、8009端口避免冲突;nginx通过upstream定义后端池并用proxy_pass转发请求,配合proxy_set_header传递真实客户端ip等关键头信息。

用 Nginx 给多个 Tomcat 实例做负载均衡,核心是两步:让每个 Tomcat 能独立运行不端口冲突,再让 Nginx 把请求合理分发过去。关键不在 Java 代码本身,而在服务部署和 Nginx 配置的协同。
Tomcat 多实例必须改端口
同一台机器上起多个 Tomcat,三个端口必须互不重复:HTTP 访问端口(默认 8080)、Shutdown 端口(默认 8005)、AJP 端口(默认 8009)。比如:
- Tomcat1:HTTP → 8080,Shutdown → 8005,AJP → 8009
- Tomcat2:HTTP → 8081,Shutdown → 8006,AJP → 8010
- Tomcat3:HTTP → 8082,Shutdown → 8007,AJP → 8011
修改位置都在 conf/server.xml 文件中,对应 `./startup.sh)并确认端口监听正常(netstat -tuln | grep :808[12])。
Nginx upstream 定义后端池
在 Nginx 的 nginx.conf 或 conf.d/*.conf 中添加 upstream 块,列出所有 Tomcat HTTP 地址:
upstream tomcat_backend {
server 127.0.0.1:8080;
server 127.0.0.1:8081;
server 127.0.0.1:8082;
}
这定义了一个名为 tomcat_backend 的服务组。支持多种调度策略:
你接手一个需求时,是不是经常这样:"改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续";这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境(JDK、Spring Boot、ORM、数据库、前端框架),记在
- 轮询(默认):请求依次分发
-
weight=2:加权轮询,如server 127.0.0.1:8080 weight=3;表示该实例承担 3 倍流量 -
max_fails=3 fail_timeout=30s:连续失败 3 次,30 秒内不再转发请求
反向代理配置要带关键 Header
在 server 块里,把请求代理到 upstream,并补全真实客户端信息:
location / {
proxy_pass http://tomcat_backend;
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;
}
这几行很重要:Host 保证 Tomcat 正确解析虚拟主机;X-Real-IP 和 X-Forwarded-For 让 Java 应用能拿到用户真实 IP,而不是 Nginx 的本地地址;否则日志、限流、安全校验都会出问题。
Session 一致性不能只靠 Nginx
Nginx 的 ip_hash 可强制同一 IP 总打到同一台 Tomcat,但不推荐——它破坏负载均衡公平性,且 NAT 环境下多个用户共用一个出口 IP,会集中压垮某台实例。
更稳妥的做法是:由 Tomcat 集群自身处理 session 共享,例如:
- 启用 Tomcat 的
DeltaManager或BackupManager(需配置cluster节点) - 使用 Redis 存储 session(推荐,解耦强、扩展性好)
- 应用层无状态化,session 数据存在前端 Cookie(加密签名)或数据库
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










