Sticky Session/Session Affinity负载消除策略的优缺点？

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

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

该问题的一个解决方案是"粘性会话"(又名"会话亲和性"),其中每个用户被分配给单个服务器,并且他/她的状态数据在整个会话期间专门包含在该服务器上.

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

优点:

这很简单 - 无需更改应用程序.

更好地利用本地RAM缓存(例如,查找用户配置文件一次,缓存它,并可以在来自同一用户的后续访问中重复使用它)

缺点:

如果服务器出现故障,则会话丢失.(请注意,这是在Web服务器上本地存储会话信息的内容 - 而不是粘性会话本身).如果会话中的内容对用户(例如草稿电子邮件)或网站(例如购物车)非常重要,那么丢失一台服务器可能会非常痛苦.

根据负载均衡器中的"粘性"实现,可能会将不等负载引导到某些服务器而不是其他服务器

将新服务器联机并不会立即给新服务器带来大量负载 - 如果您有一个动态负载平衡系统来处理峰值,那么粘性可能会降低您对峰值做出快速响应的能力.也就是说,这有点像一个角落的情况,实际上只适用于非常大而复杂的网站.

如果您的用户相对较少,但单个用户的流量可以淹没一个服务器(例如,带有SSL的复杂页面,AJAX,动态生成的图像,动态压缩等),那么粘性可能会损害最终用户的响应时间,因为您不是在服务器之间均匀分布单个用户的负载.如果你有很多并发用户,这是一个非问题,因为你的所有服务器都会被淹没!

但是如果你必须使用服务器本地会话状态,那么粘性会话绝对是可行的方法 - 即使你不使用服务器本地会话状态,粘性也会带来好处(参见上文).您的负载均衡器应该能够查看HTTP cookie(不仅是IP地址)以确定粘性,因为IP地址可以在单个会话期间发生变化(例如,在有线和无线网络之间对接笔记本电脑).

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

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