session - 粘性 session / session 亲和性负载平衡策略的优缺点？

Question

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

这种方法提出的一个挑战是服务器是否具有状态意识 - 将用户状态存储在“ session ”中。

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

“粘性 session ”方法的优点和缺点是什么？您使用过它吗？如果使用过，您对它满意吗？

Answer 1

优点:

• 这很简单 - 无需更改应用。
• 更好地利用本地 RAM 缓存(例如，查找用户个人资料一次，将其缓存，并可以在同一用户的后续访问中重复使用它)

缺点:

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

但是，如果您必须使用服务器本地 session 状态，那么粘性 session 绝对是最佳选择。即使您不使用服务器本地 session 状态，粘性在缓存利用率方面也有好处(见上文)。您的负载均衡器应该能够查看 HTTP cookie(不仅仅是 IP 地址)来确定粘性，因为 IP 地址可能在单个 session 期间发生变化(例如，在有线和无线网络之间插入笔记本电脑)。

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

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