【发布时间】：2010-11-05 14:48:55
【问题描述】：
在负载平衡服务器的上下文中，会话亲和性和粘性会话有什么区别？
【问题讨论】：
【发布时间】：2010-11-05 14:48:55
【问题描述】：
我见过这些术语可以互换使用，但有不同的实现方式：
- 在第一个响应时发送一个 cookie，然后在后续响应中查找它。 cookie 说明要发送到哪个真实服务器。
不好如果您必须支持无 cookie 浏览器 - 基于请求者的 IP 地址进行分区。
不好如果它不是静态的，或者如果许多通过同一个代理进入。 - 如果您对用户进行身份验证，请根据用户名进行分区（必须是支持 HTTP 的身份验证模式才能执行此操作）。
- 不需要状态。
让客户端访问任何服务器（将状态发送给客户端并让它们发回）
这不是一个棘手的会话，它是一种避免必须这样做的方法。
我怀疑sticky 可能指的是cookie 方式，并且在某些情况下，affinity 可能指的是#2 和#3，但我没有看到它使用（或自己使用）
【讨论】：
-
如果请求绑定到物理服务器，如果该服务器发生故障会发生什么？是否有使用 cookie 来包含故障转移服务器的策略？
-
如果服务器出现故障，应用程序也会出现故障——也许您需要重新登录。也许您丢失了数据。通常，负载平衡器会选择另一台服务器，然后您继续前进，但某些状态会丢失。如果这是不可接受的，那么您需要尽快将状态发送到数据库或其他服务器，或者采用无状态策略。
-
FWIW Heroku 将它们称为相反的。 Session Afifinity 是基于 cookie 的，它不支持粘性。 devcenter.heroku.com/articles/session-affinity
我经常听到负载平衡场景中使用的术语，它们是可以互换的。两者都意味着一旦会话启动，同一台服务器会为该会话的所有请求提供服务。
【讨论】：
粘性会话意味着当一个请求从客户端进入站点时，所有进一步的请求都会转到同一服务器，初始客户端请求被访问。我相信会话亲和力是粘性会话的同义词。
【讨论】：
它们是一样的。
两者都意味着当进入负载均衡器时，请求将被定向到为第一个请求提供服务的服务器（并具有会话）。
【讨论】：
粘性会话意味着将特定会话的请求路由到为该会话提供第一个请求的同一台物理机器。
【讨论】：
本文为我澄清了这个问题，并讨论了其他类型的负载平衡器持久性。
Dave's Thoughts: Load balancer persistence (sticky sessions)
【讨论】：
-
貌似不再可用，但有一个copy in the Wayback machine
-
这就是为什么你不只是发布链接而没有解释
-
发现上面链接的内容（现在已经没有了）已经移到archive.li/SG4fA了，基本罗列了F5负载均衡器支持的各种持久化类型。
它们是同义词。 完全没有区别
粘性会话/会话关联性：
保留用户会话与发送用户请求的服务器之间的亲和力/粘性/联系。
【讨论】：
此链接的主要部分：
亲和性：当我们使用来自应用层之下的层的信息来维护对单个服务器的客户端请求时。在这种情况下使用客户端的 IP 地址。在同一会话期间，IP 地址可能会发生变化，然后连接可能会切换到不同的服务器。
持久性：这是我们使用应用层信息将客户端固定到单个服务器的时候。在这种情况下，负载均衡器会在响应中注入一些 cookie，并在后续请求中使用相同的 cookie 路由到同一服务器。
粘性会话：粘性会话是由持久性维护的会话
持久性优于亲和性的主要优点是它更准确，但有时，持久性是不可行的（当客户端不允许像无cookie浏览器这样的cookie时），所以我们必须依赖亲和性。
使用持久性意味着我们 100% 确定用户将被重定向到单个服务器。 使用亲和力，我们的意思是用户可能会被重定向到同一个服务器……
【讨论】：