粘性会话/会话亲和力负载平衡策略的优缺点? [英] Pros and Cons of Sticky Session / Session Affinity load blancing strategy?

问题描述

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

One approach to high scalability is to use network load balancing to split processing load between several servers.

此方法提出的一个挑战是服务器要了解状态-在会话"中存储用户状态.

One challenge that this approach presents is where servers are state aware - storing user state in a "session".

解决此问题的一种方法是粘性会话"(又称会话亲缘关系")，其中，每个用户都分配给单个服务器，并且在整个会话期间，他/她的状态数据仅包含在该服务器上.

One solution to this problem is "sticky session" (aka "session affinity") where each user is assigned to a single server and his/her state data is contained on that server exclusively throughout the duration of the session.

粘性会话"方法的优缺点是什么?您使用它吗?如果满意，您对此感到满意吗?

What are the Pros and Cons of the "sticky session" approach? Do you use it and if so are you satisfied with it?

推荐答案

优点:

• 这很容易-无需更改应用程序.
• 更好地利用本地RAM缓存(例如，一次查询用户个人资料，将其缓存，并可以在同一位用户的后续访问中重新使用它)

缺点:

• 如果服务器出现故障，会话将丢失. (请注意，这是将会话信息本地存储在Web服务器上的一种手段，而不是粘性会话本身).如果会话中的内容对于用户(例如草稿电子邮件)或站点(例如购物车)确实很重要，那么丢失一台服务器可能会非常痛苦.
• 取决于负载均衡器中的粘性"实施，可能会将不相等的负载定向到某些服务器与其他服务器上.
• 使新服务器联机不会立即给新服务器带来很多负载-如果您有一个动态的负载平衡系统来应对峰值，那么粘性可能会降低您对峰值的快速响应的能力.就是说，这在某种程度上是一个极端情况，实际上仅适用于非常大型和复杂的站点.
• 如果您的用户相对较少，但是一个用户的流量会淹没一台服务器(例如，具有SSL，AJAX的复杂页面，动态生成的图像，动态压缩等)，则胶粘剂可能会损害最终用户的响应时间，因为您不会在服务器之间平均分配单个用户的负载.如果您有很多并发用户，那么这不是问题，因为所有服务器都将被淹没！

但是，如果必须使用服务器本地会话状态，则必须使用粘性会话-即使不使用服务器本地会话状态，在缓存利用率方面，粘性也有好处(请参见上文) ).您的负载平衡器应该能够查看HTTP cookie(不仅是IP地址)来确定粘性，因为IP地址可以在单个会话中更改(例如，将便携式计算机对接在有线和无线网络之间).

But if you must use server-local session state, sticky sessions are definitely the way to go-- and even if you don't use server-local session state, stickiness has benefits when it comes to cache utilization (see above). Your load balancer should be able to look at HTTP cookies (not only IP address) to determine stickiness, since IP addresses can change during a single session (e.g. docking a laptop between a wired and wireless network).

更好的是，根本不要在Web服务器上使用会话状态！如果会话状态非常令人迷失(例如购物车)，请将其存储在中央数据库中并定期清除旧会话.如果会话状态不是很关键(例如用户名/头像URL)，则将其粘贴到cookie中-只要确保您没有在cookie中添加过多数据即可.

Even better, don't use session state on the web server at all! If session state is very painful to lose (e.g. shopping carts), store it in a central database and clear out old sessions periodically. If session state is not critical (e.g. username/avatar URL), then stick it in a cookie-- just make sure you're not shoving too much data into the cookie.

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

Modern versions of Rails, by default, store session variables in a cookie for the reasons above. Other web frameworks may have a "store in cookie" and/or "store in DB" option.

这篇关于粘性会话/会话亲和力负载平衡策略的优缺点?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！