Keepalived 实现 IP 漂移不提供会话保持，需 Nginx 或应用层配合；IP 漂移保障高可用，会话保持确保请求路由至同一后端，二者目标不同但需协同。
Keepalived 实现 IP 漂移本身不直接提供会话保持能力，会话保持需由上层应用或 Nginx 本身配合其他机制协同完成。IP 漂移解决的是高可用（VIP 切换），而会话保持解决的是用户请求连续落到同一后端节点——二者目标不同，但常需共存于生产环境。
理解 IP 漂移与会话保持的边界
Keepalived 通过 VRRP 协议在主备节点间抢夺虚拟 IP（VIP）。当主节点宕机，VIP 迁移到备节点，客户端流量自动转向新主机。但此时：
- Nginx 进程重启或 reload 可能中断已有连接，导致长连接断开；
- 若后端是多台服务器（如 Tomcat 集群），VIP 切换本身不改变 Nginx 的 upstream 路由逻辑，原有 session 仍可能被转发到原节点（已不可达）；
- 浏览器或客户端缓存 DNS 或连接池，可能短暂继续访问旧地址（尤其未启用健康检查时）。
在 Nginx 层实现会话保持的常用方式
若后端服务无共享 Session 存储（如 Redis），需让相同用户始终打到同一后端。Nginx 提供几种内置策略：
- ip_hash：按客户端真实 IP 哈希，保证同一 IP 请求固定路由。注意：NAT 环境下所有内网用户会被视为同一 IP，不适用；
- hash $cookie_jsessionid;：提取 JSESSIONID Cookie 值做哈希，适合 Java 应用，前提是 Cookie 未被篡改且稳定；
-
sticky cookie（需 nginx-plus 或第三方模块）：如
nginx-sticky-module，可设置过期时间、安全标志等，更灵活可靠； - 结合 upstream health_check（需 stream 或 http 模块支持），自动剔除不可达后端，避免请求发往已离线节点。
Keepalived 切换时减少会话中断的关键配置
即便有会话保持，VIP 切换瞬间仍可能丢包或连接重置。可通过以下方式缓解：
- Keepalived 中设置
garp_master_delay 1和notify_master脚本，在 VIP 绑定后延迟几秒再启动 Nginx 或触发 reload，确保内核路由就绪； - Nginx 配置
keepalive_timeout 75s和keepalive_requests 100，复用连接，降低切换时新建连接压力； - 后端应用开启 session 复制（如 Tomcat cluster）或接入分布式 session 存储（Redis + Spring Session），使会话状态不依赖单点；
- 客户端侧配合：前端使用 retry 机制、短超时 + 重试，避免卡在失败请求上。
验证与监控建议
仅靠配置无法保证效果，需实际验证：
- 手动 stop keepalived 主节点，观察 VIP 是否秒级漂移（
ip a查看）、Nginx 日志是否持续接收请求； - 用 curl 或浏览器反复刷新，检查 Set-Cookie 中的 session ID 是否不变，后端 access.log 中来源 IP+端口是否稳定；
- 在 Nginx 中开启
log_format记录$upstream_addr和$cookie_xxx，确认路由一致性； - 对 upstream 添加
slow_start=30s，避免备节点刚上线就承接全部流量，造成雪崩。
不复杂但容易忽略：IP 漂移只是高可用的第一步，会话连续性取决于整个链路的设计闭环——从负载均衡策略、后端状态同步，到客户端容错能力，缺一不可。
