ip_hash不提供会话复制，仅实现请求路由固定；真正减少单点依赖需结合Redis等共享存储实现Session集中管理，并辅以健康检查与合理超时机制。
ip_hash 本身不支持会话复制，它只是把同一 IP 的请求固定转发到某台后端，和“复制 Session”是两件事。想减少单点依赖，不能靠 ip_hash 实现复制，而是得让所有后端共享同一份会话状态。
ip_hash 只负责路由，不负责状态同步
ip_hash 的作用很明确：根据客户端 IP 哈希后取模，决定请求发给哪台 server。它不会把 Session 写到其他机器，也不会监听后端变化并同步数据。一旦那台被哈希到的服务器宕机，原 Session 就丢失了——除非你额外做了会话外置。
真正减少单点依赖的组合方式
要让 ip_hash 不再成为故障放大器，必须解耦“请求路由”和“会话存储”：
- 用 Redis 或 Memcached 存 Session：所有后端都读写同一个 Redis 实例（或集群），Session 不再绑定某台机器。ip_hash 可以继续用，但即使后端挂掉、IP 重散列，新机器也能直接从 Redis 拿到用户登录态
- 配合健康检查自动剔除异常节点：在 upstream 中启用 Nginx 原生 health_check（HTTP 状态码探测）或第三方模块（如 nginx_upstream_check_module），避免把流量打到已失联的后端
- 设置合理的超时与 fallback 逻辑：比如 Session 在 Redis 中设 30 分钟过期；应用层检测到 Session 不存在时，引导重新登录或刷新 token，而不是直接报错
配置示例（关键片段）
在 http 块中声明 upstream，并启用 ip_hash 和健康检查：
ip_hash;
server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
# 开启原生健康检查（需 Nginx 1.19+）
health_check interval=5 fails=2 passes=2 uri=/health;
}
同时确保后端应用将 Session 存入 Redis，而不是本地内存。
为什么不推荐“会话复制”方案
像 Tomcat 的 DeltaManager 或 BackupManager 这类进程间 Session 复制机制，存在明显短板：
- 网络开销大，每次写 Session 都要广播给所有节点
- 节点越多，复制延迟越高，容易出现脏读或不一致
- 无法跨语言/跨框架复用（Java 应用的复制机制对 Go/Python 后端无效）
- 扩容缩容时需同步调整复制拓扑，运维复杂度高
相比之下，Redis 共享 Session 是标准、轻量、跨技术栈的解法，也是当前生产环境的主流选择。
