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

22 domain-name-system web-server

StackOverflow/ServerFault 有多少个 Web 服务器?

如果答案是“不止一个”,那么它是否在 DNS 轮询时实现了会话粘性

Tom*_*meh 43

大型网站可能会跨多台机器进行“负载平衡”。在许多负载平衡设置中,用户可能会在会话期间访问任何后端机器。因此,存在多种方法来允许多台机器共享用户会话。

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

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

  • 不需要后端存储
  • 用户不需要每次都打同一台机器,所以可以采用DNS负载均衡
  • 从数据库机器检索会话信息没有任何延迟(因为它是随 HTTP 请求提供的)。如果您的站点由不同大陆的机器进行负载平衡,则很有用。
  • 会话中可以存储的数据量是有限的(受 4K cookie 大小限制)
  • 如果用户不应该能够看到他们会话的内容,则必须采用加密
  • 必须使用 HMAC(或类似的)来防止用户篡改会话数据
  • 由于会话数据不是存储在服务端,开发者调试起来比较困难

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

  • 现有应用程序的会话处理可能不需要更改为多台机器感知
  • 不需要共享数据库系统(或类似系统)来存储会话,可能会增加可靠性,但会增加复杂性
  • 后端机器宕机将删除在其上启动的所有用户会话。
  • 让机器停止服务更加困难。应该允许在机器上有会话以进行维护的用户在机器关闭之前完成他们的任务。为了支持这一点,Web 负载平衡器可能具有将请求“排出”到某个后端机器的功能。

共享后端数据库或键/值存储:会话信息存储在后端数据库中,所有 Web 服务器都有权查询和更新。用户的浏览器存储了一个包含标识符(例如会话 ID)的 cookie,指向会话信息。这可能是三种方法中最干净的方法:

  • 用户永远不需要暴露于存储的会话信息。
  • 用户不需要每次都打同一台机器,所以可以采用DNS负载均衡
  • 一个缺点是,无论采用哪种后端存储系统,都可能存在瓶颈。
  • 会话信息可能会过期并持续备份。

总体而言,大多数动态 Web 应用程序执行多个数据库查询或键/值存储请求,因此数据库或键/值存储是会话数据的逻辑存储位置。

  • +1 相当全面的答案,让我不用再写了。:) 就数据库存储而言,关系数据库可能是错误的。像持久性 memcached 分支之一这样的东西更好。memcachedb 可能是合适的。您还错过了在服务器之间复制会话信息的机会。这不是最好的方法,但是像tomcat这样的东西可以做到,所以值得记录。 (2认同)

小智 4

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

  • 将会话存储在关系数据库中始终是一个坏主意。您不应该使用数据库来存储瞬态数据。 (2认同)