apache本身不管理java web应用session,真正实现会话共享需tomcat集群配置:一是启用session复制(需web.xml加、server.xml配及唯一jvmroute),二是配合apache的sticky session路由(mod_jk或mod_proxy_ajp中设置route匹配),且必须验证多播可达、ip正确、对象可序列化,否则复制将静默失败。
apache 本身不管理 java web 应用的 session,它只做反向代理或负载均衡。所谓“解决分布式集群中的会话保持”,实质是 apache + 多个 tomcat(或 jboss)组成的后端集群中,确保用户请求始终能关联到正确的 session。核心不是 apache 单独搞定,而是 apache 与 tomcat 协同配合——前者负责路由,后者负责生成、复制或识别 session。
用 stickysession 实现基于 JSESSIONID 的粘性路由
这是最常用、最稳妥的生产方案。Apache 不保存 session 数据,但能解析客户端 Cookie 中的 JSESSIONID,并根据其中的 route 标识 把请求固定打到对应 Tomcat 节点。
- 每个 Tomcat 的
<engine></engine>必须配置唯一jvmRoute,例如:jvmRoute="tomcat1" - 在 Apache 的
<proxy balancer:></proxy>中,为每个BalancerMember显式指定route=xxx,且值必须与 Tomcat 的jvmRoute一致 - 添加
ProxySet stickysession=JSESSIONID|jsessionid(大小写兼容写法更安全) - 可选增强:让 Apache 自动注入路由标识,例如:
Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; Path=/;" env=BALANCER_ROUTE_CHANGED
确保 Tomcat 层支持分布式 session(复制前提)
如果业务要求节点故障时 session 不丢失(即真正“共享”),不能只靠粘性,还需 Tomcat 启用 session 复制。Apache 的 sticky 只是路由策略,复制能力完全由 Tomcat 集群承担。
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
- 应用的
WEB-INF/web.xml必须包含<distributable></distributable>标签 - Tomcat 的
conf/server.xml中,在<engine></engine>或<host></host>内嵌入完整<cluster></cluster>配置 - 推荐使用
BackupManager(只同步到一个备份节点),比默认DeltaManager更适合 4 节点以上集群 - 检查多播是否可达(如使用默认 multicast 地址
228.0.0.4:45564),并确认广播 IP 不是127.0.0.1
避免常见陷阱:路径、协议与序列化
看似配置正确却会话丢失,往往卡在细节。这些点不报错,但会让 session 复制静默失败或 sticky 生效异常。
-
路径结尾斜杠必须统一:比如
/myapp和/myapp/在 Apache 和 Tomcat 中被视为不同上下文,导致 JSESSIONID 域名或路径不匹配 -
AJP 代理勿混用 ProxyPassMatch:若用
mod_proxy_ajp,应只用ProxyPass /app ajp://...;禁用类似ProxyPassMatch ^/(.*\.jsp)$的正则匹配,否则降级走 HTTP,绕过 AJP 的 route 识别逻辑 - session 对象必须可序列化:Tomcat 复制 session 时会尝试序列化所有属性,任何不可序列化的对象(如含 ServletContext 引用的 Bean)将导致复制中断,日志里可能只有 WARN 级别提示
备选方案:Session Server(解耦存储)
当集群规模大、复制开销高,或需跨技术栈(如 Java + Node.js 共享登录态)时,可把 session 存到外部服务,Apache 不参与 session 管理,只做纯流量转发。
- 用 Memcached 或 Redis 配合
memcached-session-manager或tomcat-redis-session-manager插件 - 此时 Apache 只需普通负载均衡(
lbmethod=byrequests),无需 sticky 配置 - 优势是彻底消除节点间网络依赖,故障转移快;缺点是引入新组件,需保障缓存服务高可用









