57

实现高可扩展性的一种方法是使用网络负载平衡在多个服务器之间分配处理负载。

这种方法提出的一个挑战是服务器是状态感知的——将用户状态存储在“会话”中。

这个问题的一种解决方案是“粘性会话”（也称为“会话亲和性”），其中每个用户都被分配到一个服务器，并且他/她的状态数据在整个会话期间专门包含在该服务器上。

“粘性会话”方法的优点和缺点是什么？你用过吗？如果用过，你满意吗？

4

1 回答 1

79

优点：

  • 这很容易——无需更改应用程序。
  • 更好地利用本地 RAM 缓存（例如，查找用户配置文件一次，将其缓存，并且可以在同一用户的后续访问中重新使用它）

缺点：

  • 如果服务器出现故障，会话将丢失。（请注意，这是将会话信息本地存储在 Web 服务器上的一个缺点——而不是粘性会话本身）。如果会话中的内容对用户（例如电子邮件草稿）或站点（例如购物车）非常重要，那么丢失您的服务器可能会非常痛苦。
  • 根据负载均衡器中的“粘性”实现，可能会将不相等的负载定向到某些服务器与其他服务器
  • 使新服务器联机并不会立即给新服务器带来大量负载——如果您有一个动态负载平衡系统来处理峰值，那么粘性可能会降低您对峰值快速响应的能力。也就是说，这在某种程度上是一个极端情况，实际上只适用于非常大和复杂的网站。
  • 如果您的用户相对较少，但单个用户的流量可能会淹没一台服务器（例如使用 SSL、AJAX、动态生成的图像、动态压缩等的复杂页面），那么粘性可能会损害最终用户的响应时间，因为您不是将单个用户的负载均匀分布在服务器上。如果您有很多并发用户，这不是问题，因为您的所有服务器都会被淹没！

但是如果你必须使用服务器本地会话状态，粘性会话绝对是要走的路——即使你不使用服务器本地会话状态，粘性在缓存利用率方面也有好处（见上文）。您的负载平衡器应该能够查看 HTTP cookie（不仅是 IP 地址）来确定粘性，因为 IP 地址可以在单个会话期间更改（例如，将笔记本电脑停靠在有线和无线网络之间）。

更好的是，根本不要在 Web 服务器上使用会话状态！如果会话状态丢失非常痛苦（例如购物车），请将其存储在中央数据库中并定期清除旧会话。如果会话状态不重要（例如用户名/头像 URL），则将其粘贴到 cookie 中——只要确保您没有将太多数据放入 cookie 中。

由于上述原因，现代版本的 Rails 默认将会话变量存储在 cookie 中。其他 Web 框架可能具有“存储在 cookie”和/或“存储在 DB”选项。

于 2009-10-15T06:51:13.130 回答