apache负载均衡下表单数据不丢失的关键是会话粘滞（stickysession）、前端本地暂存+异步持久化、后端共享session存储三者协同：1.配置route与jvmroute匹配实现jsessionid粘性路由；2.前端用localstorage定时保存草稿，后端提供draft接口存redis；3.集群改用redis集中式session管理。
Apache 本身不直接管理用户表单数据的持久化或会话状态，它作为反向代理或负载均衡器，只负责将请求转发给后端节点。表单数据是否丢失，关键不在 Apache 的负载均衡配置，而在于整个应用层的会话保持（Session Stickiness）与状态容灾设计。当某个 Tomcat 或后端节点宕机时，若用户正在填写表单、尚未提交，且该请求被后续重试打到其他节点，而新节点没有原始会话上下文，就极易导致数据“丢失”——实际是会话中断、上下文不可见。
下面从三个核心环节说明如何系统性规避这个问题：
1. 启用基于 Cookie 的会话粘滞（Sticky Session）
确保同一用户的多次请求（包括表单加载、AJAX 校验、提交前预存等）始终路由到同一台后端服务器，避免会话分裂。
# httpd.conf 或虚拟主机配置中启用 mod_proxy_balancer
<proxy>
BalancerMember http://192.168.1.10:8080 route=server1 loadfactor=1
BalancerMember http://192.168.1.11:8080 route=server2 loadfactor=1
ProxySet stickysession=ROUTEID
</proxy>
# 配合 Tomcat 的 jvmRoute（在 server.xml 的 Engine 标签中设置）
<engine name="Catalina" defaulthost="localhost" jvmroute="server1"></engine>
Tomcat 会在 JSESSIONID Cookie 后自动追加 . + jvmRoute（如 JSESSIONID=abc123.server1），Apache 通过 stickysession=ROUTEID 解析并绑定路由。这样只要该节点在线，用户就不会“跳节点”。
2. 表单数据本地暂存 + 异步持久化（前端+后端协同）
不要依赖服务端会话保存未提交的表单草稿；应在浏览器端实时缓存，并可选同步到后端统一存储。
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
-
前端建议：使用
localStorage或sessionStorage监听输入事件，定时保存草稿（如每 30 秒或 onblur 时）； -
后端配合：提供
/api/draft/save接口，接收 JSON 表单数据，存入 Redis 或数据库，主键用用户 ID + 表单业务 ID（如draft:uid123:applyLoan）； - 恢复逻辑：页面加载时检查 localStorage，如有未提交草稿则自动填充；同时发请求查服务端最新草稿，以服务端为准做合并或覆盖提示。
这种方式彻底解耦了负载均衡节点故障的影响——用户换设备、刷新页面、甚至切换集群，只要登录态有效，就能恢复。
3. 后端共享会话存储（兜底方案）
当确实需要服务端维持会话级中间状态（如多步向导中的 step 缓存），就不能依赖单节点内存会话。
- 将 Tomcat 的 session 存储改为集中式：
- 使用
RedissonSessionManager或tomcat-redis-session-manager，把 session 写入 Redis； - 所有 Tomcat 节点配置相同 Redis 地址，故障切换后新节点可立即读取原有 session；
- 使用
- 注意：表单数据本身不宜全塞进 session（体积大、序列化风险高），更适合存轻量标识（如
draftId=xxx），真实数据走独立 draft 表。
⚠️ 补充提醒：Apache 的
ProxySet failonstatus=503或健康检查（ping=10）可加快故障节点摘除，但无法解决“正在输入中节点突然宕机”的瞬时问题——这正是需要前端暂存 + 后端 draft 服务来覆盖的场景。
不复杂但容易忽略。
