粘性会话与共享位置答案

【问题标题】：Sticky session vs shared location粘性会话与共享位置
【发布时间】：2011-06-18 04:58:42
【问题描述】：

我正在对某个 drupal 站点进行负载平衡，两台服务器运行完全相同的站点，数据库运行在另一台可以访问的服务器上，以及另一台运行负载平衡器的服务器上。

我正在关注这个guide，我想知道那个粘性会话部分。由于我将所有共享静态数据存储在 NAS 中，两个 drupal 服务器都可以访问，为什么不在两个 drupal 的 PHP.ini 中定义将 session.save_path 服务到该 NAS 上的某个位置，而不是使用粘性会话？那行得通吗？

这样做有什么好处和坏处？谢谢！

【问题讨论】：

【解决方案1】：

现在，当您想要访问任一服务器上的会话时，您必须向 NAS 发出网络请求，而不是在任一 Drupal 服务器上的内存中维护会话。基本上，它很慢。

更快的方法是从您的应用程序中完全删除 Session 并享受速度优势和管理优势。

或者，您可以使用粘性会话，但这会使您的服务器场的管理更加困难。

【讨论】：

感谢您的快速回复！完全删除会话？这将如何解决？我不确定我是否理解这个建议.. :)
您需要在应用程序的组件之间使用其他参数传递方法。所以页面 A 想要将信息传递给页面 B，您需要使用：查询参数、发布参数、cookie、数据库存储或其他一些方法而不是 Session。或者，您可以按照您已经建议的方式将会话推送到每个网络服务器都可以访问的数据存储。请不要使用 Memcached。疼痛随之而来。
memcached 作为缓存是一个完全有效的解决方案。

【解决方案2】：

对此几乎规范的答案是 memcached。如果您有多个 Web 前端，这是存储会话的方法。拥有它后，您可以通过将其用于缓存来开始探索它的速度。

【讨论】：

这是一个非常糟糕的主意； memcached 是一个缓存存储，并且由于多种原因，密钥可能随时过期，这可能会注销您的用户，并真正打扰他们。 Memcached 通常用作会话的缓存，但不用作主会话存储。请阅读 memcached 的作者this。
我不想推荐 mongodb :) 尽管 memcached 的作者发出警告，但由于速度原因，每个人都将会话存储在 memcached 中，但 IMO 完全没有根据。您退出的原因可能有很多（例如，您的浏览器崩溃并且没有写出会话 cookie），因此权衡并不可怕。
如果你能提供一些关于每个人是谁的参考，我会 ++？
memcached 会比浏览器崩溃更频繁地提前过期会话。 everyone 将其会话缓存在 memcached 中，但也将它们的副本保存在持久存储中，例如if (!fetch_from_mem()) { fetch_from_persistent(); }
我不打算评价这是否是正确的方式，但你们听起来好像没有人在内存缓存中存储会话，这完全不真实。 stackoverflow.com/questions/13946033/…