会话保持是一种负载均衡行为，用于在设定时间内将同一客户端或同一用户会话的请求持续转发到同一台后端服务器。它也常被称为粘性会话或会话亲和性。实际使用中，负载均衡器不是每次都把新请求独立分配到任意可用服务器，而是记住之前的路由结果，并在保持规则有效期间继续把该客户端送回同一个目标。

这种机制很重要，因为并不是所有应用都已经完全无状态。部分 Web 应用、登录流程、购物车、聊天会话、多步骤表单和内存中的业务流程，仍然会把临时会话数据保存在某个应用实例上。如果同一用户的后续请求被转到另一台没有本地状态的后端，就可能出现会话中断、重新登录、临时数据丢失或业务行为不一致。

因此，会话保持可以理解为负载均衡器与应用会话模型之间的协调机制。它并非所有系统都必须使用，许多现代分布式应用会专门设计成不依赖它。但是当应用状态仍然停留在某个后端实例上时，会话保持就是一种实用且有时必要的方案。

会话保持会在一段时间内把客户端绑定到同一个后端，使有状态交互在多次请求之间保持一致。

会话保持的含义

为同一个客户端会话提供一致的后端路径

从本质上看，会话保持意味着同一客户端会被重复路由到同一台后端服务器，而不是每个请求都被自由重新均衡。在普通负载均衡环境中，每个请求可能会按照轮询、最少连接、权重等算法分配到最合适的后端。启用会话保持后，负载均衡器会优先考虑该客户端的连续性，只要保持记录仍然有效，就把后续请求继续送往同一后端。

这也是会话保持经常与有状态 Web 交互联系在一起的原因。它的目标不只是路由方便，而是在应用状态尚未完全外置到共享会话存储或无状态令牌模型之前，保持应用流程的连续稳定。

在实际架构讨论中，会话保持并不是用户会主动感知的功能，而是让应用在一系列相关请求被持续处理时保持稳定的基础机制。

也称为粘性会话或会话亲和性

Session persistence、sticky sessions 和 session affinity 在负载均衡场景中经常表达非常接近的含义。不同厂商可能使用不同术语，但核心思想相同：负载均衡器会在一段时间内有意保留客户端与后端之间的关系。

理解这一点有助于阅读不同平台的技术文档。无论在 Web 运维、云平台还是 Ingress 系统中，这些术语通常都指向同一类会话亲和机制。

会话保持本身不会让应用变成有状态。它只是通过把用户在部分会话生命周期内绑定到同一后端，帮助有状态应用保持行为一致。

会话保持如何工作

负载均衡器先做初始路由决策

多数会话保持流程都从一次普通负载均衡选择开始。第一次请求到来时，负载均衡器会根据配置算法选择后端，例如轮询、最少连接、加权路由或其他方式。初始目标确定后，保持机制会记录足够的信息，以便之后识别同一个客户端。

这点很关键，因为会话保持通常不是完全替代负载均衡，而是改变第一次路由之后的处理方式。初始请求、故障后的重新分配以及保持记录过期后的选择，仍然依赖负载均衡算法。

换句话说，第一次请求通常仍然被负载均衡，而后续请求可能按亲和关系转发。

系统保存亲和键

第一次请求被分配后，平台需要一种方法来识别同一客户端后续请求。不同的会话保持方法使用不同的键值：有些使用 Cookie，有些使用源 IP 地址或哈希逻辑，还有些会使用更贴近应用层的自定义数据。

只要这个键存在，后续请求就可以在保持记录有效且后端仍可用的情况下匹配到同一服务器。因此，亲和键是否准确代表真实网络和应用环境中的一个用户会话，会直接影响保持效果。

会话保持的质量很大程度取决于所选键在整个会话生命周期中是否稳定、唯一且适合该业务场景。

后续请求复用同一后端

当同一客户端再次访问时，负载均衡器会检查保持记录。如果找到有效匹配，就将请求转发到原来的后端，而不是重新做一次新的均衡决策。这个过程会持续到保持时间过期、后端不可用、保持数据变化，或平台策略要求重新计算亲和关系为止。

这种行为可以在应用期望单节点连续性的情况下，保持登录状态、购物车或多步骤流程的稳定。没有会话保持，后续请求可能落到另一台不了解该会话状态的后端。

因此，会话保持通常要和会话超时策略、故障处理、负载均衡健康检查一起设计，而不能只当作一个简单开关。

会话保持会在第一次请求后创建亲和记录，并在后续请求中复用该后端选择。

常见的会话保持方法

基于 Cookie 的保持

基于 Cookie 的保持是 HTTP 和 Web 应用环境中最常见的方法之一。负载均衡器或应用会设置一个 Cookie，用于标识会话与后端之间的关系。后续请求携带该 Cookie 时，就会在配置时长内被路由回同一台后端服务器。

这种方式非常适合浏览器型工作流，也常用于购物、认证和门户类应用，因为 Cookie 天然适合 HTTP/HTTPS 中反复发生的用户交互。在公共互联网和共享网络环境中，它通常也比简单的网络层方法更精准。

当浏览器参与是业务流程核心时，Cookie 保持通常是传统 Web 应用会话连续性的强默认选择。

基于源 IP 或哈希的保持

另一种常见方法是根据客户端源 IP 地址或某个请求属性的哈希值实现保持。这种方式部署简单，因为它不要求应用 Cookie，但也存在限制。位于共享 NAT 网关后的用户可能被错误地归为同一组，移动或漫游用户在公网 IP 变化时也可能失去保持关系。

因此，源 IP 保持通常更适合受控环境，而不是不可预测的互联网大规模客户端群体。它仍然可以在企业内网、内部应用或某些基础设施场景中发挥作用。

这种方法的简单性很有吸引力，但真正价值取决于输入属性在会话生命周期中是否足够稳定和唯一。

应用感知或自定义保持

一些平台支持更高级的保持方式，可以使用应用数据、协议字段或自定义匹配逻辑，而不只是 Cookie 或 IP 地址。当应用具有更复杂的会话身份模型，或标准 Cookie 方法不够时，这类保持方式非常有价值。

它也说明会话保持可以根据应用层进行调优，而不是固定不变的单一功能。在大型或专业环境中，它可能比通用方法产生更可靠的亲和效果。

但高级保持通常比标准 Cookie 粘性需要更谨慎的设计、测试和运维理解。

最合适的保持方法取决于应用如何识别用户会话，而不只是负载均衡器支持什么功能。

会话保持的优势

为有状态应用提供会话连续性

会话保持最直接的优势是连续性。如果应用把临时会话数据本地保存在某个后端实例上，保持机制可以让用户继续与同一实例交互，而不是在节点之间不可预测地跳转。

这可以减少会话中断、反复登录、表单部分丢失和应用行为不一致。对于较旧的应用或快速部署的 Web 工作负载，它可能是保持稳定用户体验的最简单方法。

在某些环境中，会话保持不只是有帮助，而是让会话型应用在负载均衡下可用与不稳定之间的关键差异。

在某些情况下简化应用架构

当替代方案需要立即把所有会话状态迁移到分布式共享存储时，会话保持也可以简化应用设计。团队可以在水平扩展的同时继续依赖本地会话状态，至少在架构成熟度过渡阶段可以这样做。

这并不意味着会话保持总是理想的长期设计，但它确实很实用。它允许团队在不一次性重构所有依赖会话的功能时支持连续性。

这也是工程师最终更偏好无状态模型的情况下，粘性会话仍经常出现在真实生产系统中的原因之一。

潜在的性能收益

会话保持也可能带来性能收益。如果同一后端本地保留了用户临时状态或热缓存，重复请求就可以避免反复重建状态或跨节点同步。在短期重复交互较多的负载中，即使保持的主要目的不是速度，也会让应用感觉更灵敏。

当应用在本地内存中维护热会话数据，而原本需要每次查询共享存储或重建状态时，这种收益会更加明显。

因此，在合适的工作负载中，会话保持可以同时改善用户连续性和后端效率。

当重复用户请求依赖仍绑定在特定后端实例上的临时状态时，会话保持最有价值。

取舍与限制

负载分布可能不够均匀

会话保持的主要取舍是降低了纯负载均衡的灵活性。如果用户必须回到同一后端，平台就不能根据当前负载自由重新分配每个请求。如果某些持久会话负载很重或持续时间很长，就可能造成流量分布不均。

实际上，管理员需要同时关注单个会话行为和整体节点利用率。粘性会话可以提升连续性，但如果会话群体本身没有均衡好，也会形成热点。

这也是会话保持应该有意识地启用，而不是默认启用的重要原因之一。

故障切换更复杂

会话保持还会让故障切换更复杂。如果后端服务器不可用，保持记录可能不再指向有效目标。平台必须打破粘性、重新分配会话，或让用户重新建立状态。因此，最好让应用能容忍重新分配，或仍然具备某种外部会话恢复机制。

换句话说，会话保持有助于连续性，但不能替代弹性的应用状态管理。如果绑定节点故障，而状态又不存在于其他地方，用户中断仍然很可能发生。

良好的会话架构需要在保持便利性和优雅故障处理之间取得平衡。

不适合完全无状态架构

许多现代云原生架构会刻意避免依赖粘性会话。它们把会话状态外置到共享数据存储、令牌、缓存或分布式身份层，使任意健康后端都可以处理任意请求。在这些架构中，会话保持可能不必要，甚至会因为限制负载均衡灵活性而不理想。

因此，会话保持应当被视为一种设计选择，而不是自动默认项。它在应用模型需要时很有用，但并非每个应用都应该依赖它。

对现代平台设计而言，一个简单原则是：当保持机制能解决真实状态问题时使用它；当无状态模式已经更好地解决问题时避免使用它。

会话保持常常是实用方案，但不是通用最佳实践。它的价值取决于应用是否仍依赖后端本地会话状态。

会话保持的应用场景

带登录状态的 Web 应用

最常见的应用之一是登录型 Web 应用，其中认证状态、用户流程或临时上下文仍保存在某个后端实例上。会话保持可以确保后续已认证请求继续到达同一服务器。

这对旧式 Web 平台、定制企业门户或混合现代化环境尤其相关，因为这些系统的会话状态可能尚未完全外置。

对这类应用，会话保持经常是传统会话处理与现代负载均衡基础设施之间的运维桥梁。

购物车和电商流程

当购物车内容、临时定价逻辑或结账状态本地保存在某个应用实例上时，电商系统经常使用会话保持。在这些流程中，保持机制可以避免结账体验中断和临时会话数据反复重建。

这是一个经典场景，因为客户通常会在短时间内完成一系列相关操作，而丢失会话连续性会立即产生业务影响。

当购物车和结账状态仍然是节点本地状态时，会话保持具有很高价值。

多步骤表单和交易流程

使用多步骤表单、引导式注册或分阶段交易流程的应用，如果每一步都依赖前一步产生的临时内存状态，也可以从会话保持中受益。通过让用户在流程期间停留在同一后端，负载均衡器降低了中途丢失连续性的风险。

这适用于注册系统、内部业务门户、理赔流程、支持门户和管理工作流等场景，其中会话不仅包含认证状态，还包含流程状态。

这些流程通常会非常明显地暴露会话不一致问题，因此往往最先采用会话保持。

聊天、实时 Web 会话和 API 网关

在某些聊天应用、实时有状态交互和 API 网关场景中，会话保持也很有用，因为上游服务可能期望同一节点连续处理。在 API 环境中，当后端本地缓存或交易上下文让重复路由更有价值时，可以选择性使用保持机制；但许多 API 平台仍优先采用无状态设计。

对实时或会话型服务，将同一交互保持在一个节点上可以减少状态重建并提升连续性，尤其适合过渡型架构。

与其他场景一样，决策取决于会话或对话状态实际存放在哪里。

Kubernetes 和 Ingress 环境

云原生和 Kubernetes 部署也会在特定工作负载中使用会话保持。它特别适合迁移阶段、有状态 Web 工作负载，或集群中仍有部分服务尚未完全改造为无状态的情况。

在这些环境中，Ingress 或网关级保持可以帮助将请求稳定路由到 Pod 或上游服务，同时平台仍然可以利用统一前端访问和可扩展部署模式。

在承载新旧应用混合设计的真实生产集群中，它是一种常见的实用折中方案。

部署最佳实践

只在解决真实问题时使用保持

第一条最佳实践是：只有当应用确实依赖单节点连续性时才启用会话保持。如果工作负载已经是无状态的，添加粘性可能只会降低均衡灵活性而没有明显收益。保持机制应由应用行为驱动，而不是习惯性开启。

这也有助于长期保持架构清晰。团队可以在确实需要的地方使用保持，同时推动其他服务向更具弹性的共享状态或无状态模型迁移。

这种选择性方法通常能带来更健康的长期平台设计。

有意识地选择保持方法

基于 Cookie 的保持通常最适合浏览器和 Web 应用会话，源 IP 或哈希方法更适合受控环境。特殊场景可能需要更高级的应用感知方法。所选方法应匹配应用识别会话连续性的方式，也要符合客户端在网络中的真实行为。

选错方法可能导致亲和关系不稳定、错误分组或复杂度过高。最简单的方法并不总是最正确的方法。

因此，保持方法选择既是基础设施决策，也是应用设计决策。

谨慎设置超时和故障切换行为

保持时长应该足以支持用户工作流，但不应长到让过期亲和关系无意义地保留。管理员还应测试绑定后端不可用时会发生什么。良好部署需要承认：会话保持提升连续性，但不能替代故障规划。

在任何粘性会话架构中，连续性与弹性之间的平衡都是最重要的设计点之一。

配置得当时，会话保持可以支持稳定性，而不会把平台锁定到僵硬或脆弱的行为中。

FAQ

简单来说，什么是会话保持？

会话保持是一种负载均衡功能，用于让用户请求在部分会话期间继续到达同一后端服务器，而不是每次请求都独立重新分配。

会话保持和粘性会话一样吗？

是的。在负载均衡环境中，粘性会话和会话亲和性通常都是会话保持的其他叫法。

为什么有些应用需要会话保持？

有些应用会把登录状态、购物车、聊天上下文或多步骤流程数据等临时会话信息保存在某个后端实例上。保持机制可以让后续请求返回同一实例。

实现会话保持的主要方式有哪些？

常见方式包括负载均衡器 Cookie、应用 Cookie、源 IP 或哈希亲和，以及更高级的应用感知保持方法。

会话保持总是好选择吗？

不是。它适合有状态应用，但完全无状态架构通常不需要它，并且更适合更灵活的负载分布。