什么是 Session 粘滞（Sticky Session）？有什么优缺点？

别再让你的用户“迷路”一文读懂 Session 粘滞Sticky Session引言为什么你需要一个“专属医生”一、预备知识负载均衡与会话的“矛盾”1.1 为什么需要负载均衡1.2 HTTP 的无状态性1.3 集群中的“认人”难题二、什么是 Session 粘滞三、实现方案深度解析3.1 方案一基于 Cookie 的粘滞推荐3.2 方案二基于 IP 哈希简单但不完美3.3 两种方案对比四、架构对比粘滞 vs 复制 vs 集中存储五、避坑指南与生产建议5.1 粘滞 ≠ 高可用5.2 负载均衡器的超时时间必须大于 Session 超时5.3 扩容/缩容时的“会话飘移”5.4 适用场景建议六、总结引言为什么你需要一个“专属医生”想象你去一家大型连锁医院看病。第一次挂号时接待员随机给你分配了一位医生负载均衡。你向医生详细描述了病史做了检查医生给你开了处方。一周后你来复查接待员却把你分配给了另一位医生。这位医生对你的病情一无所知只能让你把所有症状再描述一遍重新开检查单——你崩溃了。这就是分布式系统中“会话丢失”的真实写照。在 Web 世界里每个用户与系统的交互就像一次完整的就医过程。如果每次请求都被随机分配到不同的服务器用户就得反复“重新介绍自己”。Session 粘滞Sticky Session正是为了解决这个问题而生——它像一根无形的线把同一个用户的所有请求“粘”在同一台服务器上。一、预备知识负载均衡与会话的“矛盾”1.1 为什么需要负载均衡当网站用户量增长到单台服务器无法支撑时我们会在多台服务器上部署相同的应用前面放一个负载均衡器如 Nginx、AWS ALB将请求分发到不同节点。这样既能扛住高并发又能避免单点故障。1.2 HTTP 的无状态性HTTP 协议天生是“健忘”的。用户第一次请求时登录第二次请求时服务器已经忘了你是谁。为了解决这个问题我们引入了Session服务器为每个用户创建会话对象通过 Session ID 识别身份。1.3 集群中的“认人”难题当负载均衡器把请求随机分发时可能出现这样的悲剧用户登录请求落到了服务器 AA 创建了 Session并存放在自己内存里。用户点击“查看购物车”负载均衡器把请求发到了服务器 B。服务器 B 的内存里没有这个用户的 Session → 判定用户未登录 → 重定向到登录页。这就是 Session 丢失为了解决这个问题业界演化出三种主流方案Session 粘滞、Session 复制、Redis 集中存储。本文聚焦第一种。二、什么是 Session 粘滞Session 粘滞又称会话保持、Sticky Session是一种负载均衡策略将同一用户的所有请求始终路由到同一台后端服务器从而让该服务器内存中的 Session 能够被复用。第一次请求分配服务器A后续请求仍发往服务器A其他用户其他用户用户浏览器负载均衡器服务器ASession存在本地内存服务器B服务器C三、实现方案深度解析3.1 方案一基于 Cookie 的粘滞推荐负载均衡器在第一次请求时在响应中插入一个特殊的 Cookie如route记录处理该请求的后端服务器标识。后续请求携带这个 Cookie负载均衡器读取后直接转发到同一台服务器。Nginx 配置示例1.29.6 版本已开源此功能upstream backend { server backend1.example.com; server backend2.example.com; sticky cookie srv_id expires1h domain.example.com path/; }参数说明cookie指定用于粘滞的 Cookie 名称expiresCookie 有效期如1h表示 1 小时domainCookie 的域名范围pathCookie 生效路径AWS ALB 实现AWS 应用负载均衡器ALB支持基于 Cookie 的粘滞会话可通过控制台或 API 启用设置stickiness.enabledtrue并指定 Cookie 持续时间。关键特性每次请求都会延长 Cookie 有效期。如果用户在 Cookie 过期前持续操作会话会一直保持。3.2 方案二基于 IP 哈希简单但不完美负载均衡器根据客户端 IP 计算哈希值将同一 IP 的请求固定发往同一台服务器。Nginx 配置示例upstream backend { ip_hash; server backend1.example.com; server backend2.example.com; }优点实现简单无需 Cookie对客户端透明。缺点NAT 穿透失败公司内网成千上万用户共享同一个出口 IP所有请求会被“粘”到同一台服务器导致负载严重不均。移动网络问题用户从 4G 切换到 WiFi 时 IP 变化可能被分配到不同服务器。代理/CDN 场景请求源 IP 都是代理服务器的 IP同样会“粘死”在一台机器上。3.3 两种方案对比对比维度基于 Cookie基于 IP 哈希实现原理插入特殊 Cookie 标识服务器根据客户端 IP 哈希计算精准度精确到单个客户端精确到 IPNAT 后失效负载均衡效果良好差NAT 环境下严重不均客户端透明性需支持 Cookie完全透明适用场景现代 Web 应用老旧系统、简单内网四、架构对比粘滞 vs 复制 vs 集中存储维度Session 粘滞Session 复制Redis 集中存储原理请求固定发往同一节点Session 数据在节点间实时拷贝Session 统一存储在 Redis性能⭐⭐⭐⭐⭐ 本地内存访问无网络开销⭐⭐ 广播风暴节点越多越慢⭐⭐⭐⭐ 一次网络请求扩展性⭐⭐ 节点数受限扩容需处理已有会话⭐ 通常限制在 8 个节点以内⭐⭐⭐⭐⭐ 节点无状态可随意扩缩容高可用❌ 节点宕机会话丢失✅ 其他节点有备份✅ Redis 集群保障实现复杂度低仅需配置负载均衡器中需配置应用服务器集群中需维护 Redis 集群适用场景小型集群、无状态改造过渡期传统应用服务器集群生产环境、大规模集群五、避坑指南与生产建议5.1 粘滞 ≠ 高可用这是最大的误区Session 粘滞只是把用户“粘”在某一台服务器上并没有解决服务器宕机时的会话丢失问题。如果该服务器崩溃该节点上的所有用户会话都会丢失。建议粘滞应被视为性能优化手段避免 Session 同步开销而非高可用方案。生产环境建议结合 Redis 集中存储或在关键场景下启用节点故障时的优雅降级。5.2 负载均衡器的超时时间必须大于 Session 超时负载均衡器维护的粘滞表项或 Cookie 有效期必须大于应用服务器的 Session 超时时间。否则用户在 Session 还未过期时粘滞关系已经失效请求可能被转发到其他节点导致会话丢失。验证示例AWS ALB 的粘滞会话持续时间如果在 Session 超时之前到期用户在 Session 有效期内访问时会被重新分配到新服务器导致登录态丢失。5.3 扩容/缩容时的“会话飘移”当集群节点增减时基于 IP 哈希的粘滞会重新计算路由大量用户的请求可能被分配到新服务器导致会话丢失。基于 Cookie 的粘滞也会因为目标服务器不存在而失效。现代方案采用一致性哈希Consistent Hashing节点增减时只有少部分用户的会话受影响。Nginx 的hash指令和 Envoy 的 Maglev 算法都支持此特性。5.4 适用场景建议场景推荐方案理由开发/测试环境粘滞IP 哈希简单无需额外组件小型集群≤4 节点粘滞Cookie性能最优配置简单企业内网应用粘滞IP 哈希网络环境可控IP 稳定大规模生产集群Redis 集中存储无状态易扩展高可用WebSocket/长连接粘滞Cookie必须保持同一连接无法共享状态六、总结要点结论核心价值避免 Session 复制和共享带来的网络开销提升集群性能实现方式基于 Cookie推荐或基于 IP 哈希简单但不完美最大局限节点宕机会话丢失不能替代高可用方案生产建议小型集群用粘滞大规模用 Redis两者并非对立可分层使用一句话总结Session 粘滞是一种用“路由确定性”换取“性能”的会话管理方案。它像一根无形的线把用户“拴”在同一台服务器上让你在无需改造应用的情况下快速获得集群能力。但它不是银弹——真正的大规模分布式系统最终还是要走向无状态架构。