Apache 不管理 Session,仅负责请求分发;Tomcat 承担 Session 管理,会话粘滞(sticky session)通过 jvmRoute 和 stickysession=JSESSIONID 实现请求绑定单节点,零复制但有单点故障风险;Redis 集中存储实现无状态共享,支持弹性伸缩与故障恢复;Tomcat 原生集群复制适用于小规模内网,依赖组播或 TCP 通信,节点增多时性能下降明显。

Apache 本身不管理 Java Web 应用的会话(Session),它只负责反向代理或负载均衡;真正的 Session 管理由后端 Tomcat(或其他 Servlet 容器)承担。所以在 Apache + Tomcat 集群架构中,会话同步问题本质是 Tomcat 节点间如何共享或一致化 Session 数据,Apache 的角色是把请求合理分发过去——而这个分发方式直接影响 Session 是否“看起来”连续。
会话粘滞(Sticky Session):最常用、最轻量的方案
通过 Apache 的 mod_jk 或 mod_proxy_balancer 模块配置会话保持,让同一用户的后续请求始终落到同一个 Tomcat 实例上。这样 Session 始终在本地内存中,无需复制或共享。
- mod_jk 方式:在 workers.properties 中启用
sticky_session=true,并确保 Tomcat 的jvmRoute在 server.xml 的 Engine 标签下唯一(如<Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat1">) - mod_proxy_balancer 方式:使用
stickysession=JSESSIONID|jsessionid参数,并开启 cookie 路由支持 - 优点:零额外存储依赖、低延迟、配置简单
- 缺点:单点故障风险——若该 Tomcat 宕机,未持久化的 Session 就丢失;扩容/缩容时用户会话可能中断
外部集中存储:真正解耦、高可用的方案
把 Session 数据从 Tomcat 内存移出,统一存到 Redis 或 Memcached 中,所有节点读写同一份数据。Apache 不参与存储逻辑,只负责转发请求。
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
- Redis 方案:集成
tomcat-redis-session-manager或 Spring Session(spring-session-data-redis),修改 Tomcat 的 context.xml 或应用的 web.xml,指定 Manager 类并配置 Redis 连接参数 - Memcached 方案:使用
memcached-session-manager,原理类似,适合已有 Memcached 基础设施的环境 - 关键点:应用需标记为可分发(
<distributable/>放入 web.xml),且避免在 Session 中存大对象或不可序列化类型 - 优势:节点无状态、弹性伸缩友好、故障自动恢复、天然支持非粘性路由
Tomcat 原生集群复制:适合小规模、同内网场景
利用 Tomcat 自带的 Tribes 框架,在多个实例间实时广播复制 Session 变更。Apache 仍做负载均衡,但所有 Tomcat 必须能互相组播或 TCP 直连。
立即学习“Java免费学习笔记(深入)”;
- 配置核心:在 server.xml 的
<Cluster>元素中启用SimpleTcpCluster,并设置 Membership(McastService 或 StaticMembership)和 Receiver - 要求:所有节点时间同步、防火墙开放组播端口(默认 45564)或 TCP 端口、网络延迟低
- 注意:Session 复制会随节点数增加呈指数级增长网络与 CPU 开销,不建议超过 5–7 个节点
补充说明:前端层的配合也很关键
Apache 的负载策略要和 Session 方案匹配:
- 用 Sticky Session 时,避免轮询(round-robin),优先选基于 Cookie 或 IP 的会话保持
- 用 Redis/Memcached 时,可放心使用轮询、加权、最少连接等任意调度算法,完全无需粘滞
- 如果用 Nginx 替代 Apache 做前置,同样适用上述三类方案,只是配置语法不同(如
ip_hash或hash $cookie_JSESSIONID)

















