Sticky Session / Session Affinity负载均衡策略的优缺点？

Question

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

这种方法提出的一个挑战是服务器可以识别状态 - 将用户状态存储在“会话”中。

此问题的一个解决方案是“粘性会话”（又名“会话关联”），其中每个用户被分配到单个服务器，并且他/她的状态数据在整个会话期间仅包含在该服务器上。

“粘性会话”方法的优点和缺点是什么？你使用它，如果是这样，你对它感到满意吗？

Answer 1

优点：

• 很容易 - 不需要更改应用。
• 更好地利用本地RAM缓存（例如，查找用户配置文件一次，缓存它，并可以在同一用户的后续访问中重复使用它）

缺点：

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

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

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

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