会话保持（Session Affinity，也常被称为 sticky session）是指负载均衡器在一段会话周期内，尽量把同一客户端的连续请求转发到同一台后端服务器的机制。它主要解决有状态 Web 应用在多台服务器之间分摊流量时，用户登录状态、购物车、临时表单或服务端缓存无法被任意节点共享的问题。会话保持不是一种独立协议，而是一类调度策略；它通常出现在 独立服务器与VPS、云主机集群、反向代理和应用交付控制器的负载均衡配置中。
从架构角度看，会话保持的核心目标是“同一用户在短时间内尽量命中同一后端”。如果某个应用把登录态保存在本机内存中，用户第一次请求被分配到 Server A，第二次请求却被分配到 Server B，就可能出现重新登录、购物车丢失或表单校验失败等现象。会话保持通过客户端 IP、Cookie、URL 参数或负载均衡器生成的标识，把请求与后端节点建立临时绑定关系，帮助旧式有状态应用在多节点环境中继续运行。
定义
在典型负载均衡架构中，用户请求先到达一个入口层，再由入口层按照轮询、最少连接数、权重或哈希等策略转发到后端服务器。无会话保持时，连续 5 次请求可能分别落到 3 台不同服务器；启用会话保持后，这 5 次请求更可能被固定到同一台服务器，直到 Cookie 过期、源地址变化、后端节点下线或绑定表失效。
会话保持常用于以下状态无法即时共享的场景：登录后会话保存在本机内存，验证码或一次性令牌只存在单节点缓存，文件上传分片依赖同一工作进程，或者旧版应用尚未改造为集中式 Session 存储。它的价值在于降低应用改造成本，但它并不等同于真正的高可用状态管理。若被绑定的后端服务器故障，仍需要额外的健康检查、故障转移和共享存储机制承担恢复工作。
详细说明
会话保持可以理解为负载均衡层维护的一张“客户端到后端节点”的映射表。第一次请求进入时，负载均衡器按普通调度算法选择一台后端；后续请求到来时，它先检查请求中是否存在可识别的绑定信息。如果绑定仍然有效，请求会被送回原节点；如果绑定过期或原节点不健康，则重新选择后端并建立新的绑定。
常见实现方式包括以下 4 类：
- 源地址哈希：根据客户端 IP 地址计算后端节点，配置简单，但在移动网络、代理出口或 NAT 环境中容易把大量用户压到同一节点。
- Cookie 绑定：负载均衡器写入或读取 Cookie，把浏览器会话与后端节点关联，适合 HTTP 应用，但需要浏览器支持 Cookie。
- 应用会话标识：根据 URL 参数、Header 或应用生成的 Session ID 做映射，灵活度较高，但要求入口层理解应用层字段。
- 一致性哈希：在节点增减时尽量减少重映射范围，常用于缓存、对象路由或连接状态较重的系统。
这些方式并没有绝对优劣，差别在于绑定粒度、故障恢复、扩容扰动和可观测性。以 Cookie 绑定为例，优点是精确到浏览器会话，缺点是后端节点变更时可能出现绑定失效；以源地址哈希为例，配置成本低，但在企业出口网关后面，几百个真实用户可能共享同一个公网 IP，导致负载不均。
会话保持与普通负载均衡的区别
普通负载均衡更关注“每一次请求如何分摊”，会话保持则额外关注“同一会话是否回到原节点”。两者可以同时存在：首次请求仍由轮询或最少连接数选择节点，后续请求再依据绑定策略转发。下表概括了两者在状态管理上的差异。
| 维度 | 普通负载均衡 | 启用会话保持 |
|---|---|---|
| 调度目标 | 尽量均衡每次请求或连接 | 尽量保持同一会话落到同一节点 |
| 典型依据 | 轮询、权重、最少连接数 | Cookie、源 IP、Session ID、哈希 |
| 状态依赖 | 更适合无状态应用 | 更适合短期有状态应用 |
| 扩容影响 | 新增节点后流量较快分散 | 旧会话可能继续停留在原节点 |
| 故障影响 | 失败请求可重试到其他节点 | 绑定节点故障时可能丢失本地状态 |
因此，会话保持通常被视为兼容方案，而不是架构终点。对新系统而言，更稳健的做法是把会话状态移出单台服务器，例如使用集中式缓存、数据库、对象存储或令牌化认证；对无法立即改造的历史系统，会话保持可以作为过渡层，减少迁移到多节点负载均衡时的业务中断。
应用场景
会话保持常出现在 Web 登录、在线支付、后台管理、分片上传和临时缓存等场景。以一个中小型电商站为例，应用服务器共有 3 台，用户登录态保存在单台服务器内存中。如果没有会话保持，用户刷新页面时可能被转到另一台服务器，导致“已登录页面变成未登录页面”。启用 Cookie 绑定后，浏览器携带负载均衡器写入的标识，后续请求会回到同一台后端，登录体验会更稳定。
另一个场景是运维后台或控制面板。部分旧版面板在执行长任务时，会把任务进度保存在本机临时目录或进程内存中。若请求在任务执行期间被分散到其他节点，页面可能无法读取进度，甚至重复提交操作。对于这类系统，短时会话保持可以降低误操作概率，同时仍应配合任务队列、数据库状态表和幂等接口设计。
在 WordPress、论坛、会员中心等内容型网站中，会话保持还可能与缓存策略同时出现。入口层既要把静态资源、页面缓存和 API 请求分开处理，也要避免把所有动态请求固定在单台服务器上。若网站同时使用 海外云主机与CDN协作架构，还需要区分边缘缓存命中和回源动态请求，避免把缓存层的问题误判为会话绑定失效。
对比与边界
会话保持能解决一部分状态连续性问题，但也会带来负载倾斜和故障恢复复杂度。最常见的风险是热点用户或代理出口导致单节点压力过高。例如企业办公网络中的 300 个员工通过同一个公网 IP 访问系统，如果使用源 IP 绑定，负载均衡器可能把这些请求都转给同一台服务器，而其他节点相对空闲。
第二个风险是扩容效果被削弱。新增后端节点后，旧会话不会自动均匀迁移，短期内新节点只能承接新会话。如果系统会话时间设置为 8 小时，扩容后的均衡效果也可能需要数小时才逐步体现。对于流量峰值明显的网站，过长的绑定有效期会让会话保持从“稳定体验”变成“阻碍扩容”。
第三个风险是节点故障时状态丢失。健康检查可以把新请求转移到健康节点，但无法恢复只保存在故障节点内存中的 Session。若业务包含支付回调、表单草稿或权限变更等关键状态，应优先把状态写入共享数据层，而不是依赖会话保持长期兜底。
配置和观测要点
评估会话保持是否合适时，重点不是“能否打开开关”，而是确认应用状态到底存在哪里。若状态已经存入集中式缓存或数据库，保持严格绑定的必要性会降低；若状态仍在本机内存，启用会话保持前应同步设置健康检查、绑定过期时间、故障转移行为和日志字段。Nginx 文档中的 HTTP 负载均衡说明、HAProxy 文档中的连接与代理配置示例，都把后端健康、转发策略和客户端识别作为入口层设计的一部分。
可观测性通常包括 4 个指标：
- 后端请求分布：观察 5 分钟、30 分钟和 24 小时窗口内各节点请求量，判断是否存在明显倾斜。
- 绑定命中率：统计同一 Cookie 或 Session ID 是否稳定落到同一后端，低命中率可能说明 Cookie 被代理剥离或配置路径不一致。
- 节点故障后的重试结果：模拟单节点下线，确认新请求能否转移，旧会话是否需要重新登录或重新提交。
- 会话时长分布：比较绑定过期时间与真实业务会话长度，避免 30 分钟业务会话配置成 24 小时绑定。
在生产系统中，常见做法是先用短绑定时间灰度验证。例如把 Cookie 绑定有效期设置为 10 到 30 分钟，观察登录错误率、后端负载差异和故障切换表现，再决定是否延长。对于管理后台，可以把绑定策略限制在特定路径；对于纯静态资源或可缓存页面，则不应使用会话保持，以免浪费后端吞吐。
常见误区
一个常见误解是把会话保持等同于高可用。实际上，它只能提高同一会话在短时间内的连续性，不能保证状态在节点故障后仍然存在。另一个误解是认为所有负载均衡都必须启用会话保持。对于无状态 API、静态站点、只读页面或已经使用集中式 Session 存储的应用，普通负载均衡通常更容易扩容，也更便于故障转移。
还有一种误解是认为源 IP 绑定足够精确。移动网络、企业代理、校园网、运营商 NAT 都可能让大量用户共享出口地址；同一用户也可能因为网络切换而更换公网 IP。相比之下，Cookie 绑定通常更适合浏览器应用，但它依赖 HTTP 层识别，无法直接覆盖所有 TCP 长连接或非浏览器客户端。
参考资料
总结
会话保持是负载均衡中的状态连续性策略，适合短期兼容有状态 Web 应用、后台系统和无法立刻共享 Session 的历史架构。它可以考虑作为迁移到多节点架构时的过渡方案，但不应替代集中式状态存储、健康检查和故障恢复设计。若系统正在规划扩容，建议先判断应用是否真正需要绑定，再选择 Cookie、源 IP 或哈希等实现方式，并用后端分布、绑定命中率和故障演练结果验证配置是否可靠。
微信扫一扫打赏
支付宝扫一扫打赏
