粘滞会话/会话相关性负载分流策略的优点和缺点？

Question

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

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

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

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

Answer 1

优点：

• 它easy--无需应用程序的变化。
• 更好地利用本地RAM高速缓存（例如查找用户配置文件一次，它缓存，并且可以重新使用它从同一个用户的后续访问）

缺点：

• 如果服务器关闭，会话丢失。 （请注意，这是将会话信息本地存储在Web服务器上的一个骗局 - 本身并不是粘滞会话）。如果会话中的内容对用户（例如电子邮件草稿）或网站（例如购物车）非常重要，那么丢失一台服务器可能会非常痛苦。
• 根据负载平衡器中的“粘性”实现，可能会导致某些服务器与其他服务器的负载不相等
• 使新服务器联机不会立即给新服务器带来很多负载 - 如果您有动态负载平衡系统来处理尖峰，粘性可能会减慢你对迅速响应的能力。也就是说，这是一个角落的情况，真的只适用于非常大的和复杂的网站。
• 如果您的用户相对较少，但单个用户的流量可能淹没一台服务器（例如，使用SSL，AJAX，动态生成的图像，动态压缩等的复杂页面），则粘附可能会伤害最终用户的响应时间不会将单个用户的负载均匀地分布在各个服务器上。如果你有很多并发用户，这是一个非问题，因为你的所有服务器都会被淹没！

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

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

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