StackOverflow/ServerFault 有多少个 Web 服务器？
如果答案是“不止一个”，那么它是否实现了会话粘性在 DNS 轮询时？
答案1
大型网站可能在多台机器上实现“负载平衡”。在许多负载平衡设置中，用户可能在会话期间访问任何后端机器。因此，存在多种方法允许多台机器共享用户会话。
选择的方法取决于所采用的负载平衡方式以及后端存储的可用性/容量：
会话信息仅存储在 cookies 中：会话信息（不仅仅是会话标识符）存储在用户的 Cookie 中。例如，用户的 Cookie 可能包含其购物篮的内容。为了防止用户篡改会话数据，可以随 Cookie 提供 HMAC。这种方法可能最不适合大多数应用程序：
- 无需后端存储
- 用户不需要每次都访问同一台机器，因此可以采用DNS负载平衡
- 从数据库计算机检索会话信息没有延迟（因为它随 HTTP 请求提供）。如果您的网站由不同大洲的计算机进行负载平衡，则很有用。
- 会话中可存储的数据量受到限制（受 4K Cookie 大小限制）
- 如果用户不希望看到其会话内容，则必须采用加密
- 必须采用 HMAC（或类似方法）来防止用户篡改会话数据
- 由于会话数据不存储在服务器端，开发人员调试起来更加困难
负载均衡器始终将用户引导至同一台机器：许多负载平衡器可能会设置其会话 cookie，指示用户从哪台后端计算机发出请求，并在将来将他们定向到该计算机。由于用户始终被定向到同一台计算机，因此不需要在多台计算机之间共享会话。这在某些情况下可能是有益的：
- 现有应用程序的会话处理可能不需要改变即可实现多台机器感知
- 不需要共享数据库系统（或类似系统）来存储会话，这可能会提高可靠性，但代价是复杂性
- 后端机器发生故障将会关闭其上启动的所有用户会话。
- 让机器停止服务更加困难。在因维护而停机的机器上拥有会话的用户应该被允许在机器关闭之前完成他们的任务。为了支持这一点，Web 负载平衡器可能具有将请求“排空”到特定后端机器的功能。
共享后端数据库或键/值存储：会话信息存储在后端数据库中，所有 Web 服务器都可以访问该数据库以进行查询和更新。用户的浏览器会存储一个包含标识符（例如会话 ID）的 Cookie，指向会话信息。这可能是三种方法中最简洁的：
- 用户永远不需要接触存储的会话信息。
- 用户不需要每次都访问同一台机器，因此可以采用DNS负载平衡
- 一个缺点是无论采用哪种后端存储系统都可能存在瓶颈。
- 会话信息可能会过期，并持续备份。
总体而言，大多数动态 Web 应用程序都会执行多个数据库查询或键/值存储请求，因此数据库或键/值存储是会话数据的逻辑存储位置。
答案2
如果您的问题是如何在多个前端 Web 服务器上维护会话，那么答案通常是使用集中式数据库。您不必依赖 Web 服务器实例来跟踪本地文件系统上的会话文件，而是将会话 ID 和数据写入中央数据库，然后所有 Web 服务器都会从那里检索数据。
答案3
使用 nemcached 似乎是一个很好的解决方案，但@David Pashley 并没有提到这一点
这意味着拥有一个由所有服务器共享的远程 memcached 实例，并使用提供其自己的会话处理程序的 memcache PECL 扩展。
只需要改变php配置中的两个参数！
这是一个很好的教程http://www.dotdeb.org/2008/08/25/storing-your-php-sessions-using-memcached/
答案4
您可以设置一个 cookie。
您可以计算远程 IP 的哈希值（最简单的是，奇数编号的远程主机转到服务器 A，偶数编号的主机转到服务器 B）。
如果您使用 SSL 隧道，看起来您也可以通过一些保留在源系统中的值来完成此操作。
通常，上述每种机制都需要一个“反向代理”服务器或某种负载平衡器。该负载平衡器会接受流量，然后根据上述条件之一将其引导至最初有会话的服务器。
不过，我不确定你所说的“DNS轮询”是什么意思