跨多个Web服务器如何实现会话粘性？

大型网站可能在多台机器上“负载均衡”。 在许多负载均衡设置中，用户可能在会话期间碰到任何后端机器。 因此，有许多方法允许许多机器共享用户会话。

所选的方法将取决于所采用的负载平衡的风格以及后端存储的可用性/容量：

会话信息仅存储在cookie中 ：会话信息（不仅仅是会话标识符）存储在用户的cookie中。 例如，用户的cookie可能包含他们的购物篮的内容。 为了防止用户篡改会话数据，HMAC可以与cookie一起提供。 这种方法可能是最不适合大多数应用的：

• 没有后端存储是必需的
• 用户不需要每次都击中同一台机器，因此可以使用DNS负载平衡
• 从数据库机器检索会话信息没有延迟（因为它与HTTP请求一起提供）。 如果您的网站通过不同大陆的机器进行负载平衡，则这很有用。
• 会话中可以存储的数据量是有限的（受到4K cookie大小的限制）
• 如果用户不能看到他们的会话内容，就必须使用encryption
• 必须采用HMAC（或类似的）来防止用户篡改会话数据
• 由于会话数据不存储在服务器端，开发人员debugging起来比较困难

负载均衡器总是将用户指向同一台机器 ：许多负载均衡器可能会设置自己的会话cookie，指示用户正在向哪个后端机器发出请求，并将其指向将来的机器。 因为用户总是定向到同一台机器上，所以不需要多台机器之间的会话共享。 这在某些情况下可能会很好：

• 现有的应用程序的会话处理可能不需要被改变成多个机器意识
• 存储会话不需要共享数据库系统（或类似的），可能增加可靠性，但代价是复杂性
• 一个后端机器将会closures所有启动的用户会话。
• 使机器停止工作更加困难。 在机器closures之前，应该允许在机器上进行会话的用户完成任务。 为了支持这一点，networking负载平衡器可能有一个function，以“请求”到某个后端机器。

共享后端数据库或键/值存储 ：会话信息存储在后端数据库中，所有的Web服务器都可以查询和更新。 用户的浏览器存储包含标识符（例如会话ID）的cookie，指向会话信息。 这可能是三者中最干净的方法：

• 用户永远不需要暴露于存储的会话信息。
• 用户不需要每次都击中同一台机器，因此可以使用DNS负载平衡
• 一个缺点是可以放在任何后端存储系统上的瓶颈。
• 会话信息可能会过期并一直备份。

总的来说，大多数dynamicweb应用程序执行一些数据库查询或键/值存储请求，所以数据库或键/值存储是会话数据的逻辑存储位置。

如果您的问题是如何维护跨多个前端Web服务器的会话，那么答案通常是使用集中式数据库。 不是依靠Web服务器实例来跟踪本地文件系统上的会话文件，而是将会话ID和数据写入中央数据库，所有Web服务器都会从那里检索数据。

使用nemcached似乎是一个很好的解决scheme，而不是像@大卫·帕什利所提到的

这意味着有一个远程memcached实例共享所有服务器和使用memcache PECL扩展提供自己的会话处理程序。

它只需要在phpconfiguration中更改两个参数！

这是一个很好的教程http://www.dotdeb.org/2008/08/25/storing-your-php-sessions-using-memcached/

IIRC，在DotNetRocks＃440他们说一个服务器时期。 不知道是否仍然如此。

编辑：其实这是Hanselminutes＃134 。 抱歉。

你可以设置一个cookie。

您可以计算远程IP的散列（在其最简单的情况下，奇数编号的远程主机转到服务器A，偶数编号的主机转到服务器B）。

看起来你也可以通过一些与源系统保持一致的值来实现，如果你使用的是SSL隧道。

通常，上述每个机制都需要一个“反向代理”服务器或某种负载均衡器。 负载均衡器接受stream量，然后根据上述标准之一将其引导至最初拥有会话的服务器。

不过，我不确定你的意思是“DNS轮询”

a）您可以将会话信息存储在用户cookie中。 查看无状态硬化cookies，在服务器端不存储数据，但保留会话状态http://www.cl.cam.ac.uk/~sjm217/papers/protocols08cookies.pdf 。 b）您可以将会话后端存储更改为数据库或memcached。 要消除单点故障，可以设置数据库复制或多个memcached节点。 请注意，memcached被推荐在这样的设置中，在会话中丢失用户状态不是很大的错误，不会让他非常不高兴。 对于保存状态至关重要的情况，请使用数据库。 PHP，Django和Rails都允许开发人员编写自定义会话后端。