粘性会话/会话亲和性负载均衡策略的优缺点? [英] Pros and Cons of Sticky Session / Session Affinity load blancing strategy?
问题描述
实现高可扩展性的一种方法是使用网络负载平衡在多个服务器之间分配处理负载.
这种方法带来的一个挑战是服务器具有状态感知能力——将用户状态存储在会话"中.
这个问题的一个解决方案是粘性会话"(也称为会话亲缘关系")，其中每个用户都被分配到一个服务器，并且他/她的状态数据在整个会话期间只包含在该服务器上.
粘性会话"方法的优缺点是什么?您是否使用过它，如果使用过，您对它感到满意吗?
优点:
- 这很简单 - 无需更改应用.
- 更好地利用本地 RAM 缓存(例如，查找一次用户配置文件，将其缓存，并且可以在同一用户的后续访问中重复使用)
缺点:
- 如果服务器出现故障，会话就会丢失.(请注意，这是将会话信息本地存储在 Web 服务器上的一种骗局——而不是粘性会话本身).如果会话中的内容对用户(例如电子邮件草稿)或站点(例如购物车)非常重要，那么丢失其中一台服务器可能会非常痛苦.
- 取决于粘性"在您的负载均衡器中实现，可能会将不均衡的负载引导至某些服务器与其他服务器
- 使新服务器联机并不会立即给新服务器带来大量负载——如果您有一个动态负载平衡系统来处理峰值，粘性可能会降低您对峰值的快速响应能力.也就是说，这在某种程度上是一种极端情况，实际上仅适用于非常大且复杂的网站.
- 如果您的用户相对较少，但单个用户的流量可以淹没一台服务器(例如，带有 SSL、AJAX、动态生成图像、动态压缩等的复杂页面)，那么即时贴可能会影响最终用户的响应时间，因为您'没有在服务器之间均匀分布单个用户的负载.如果您有很多并发用户，这不是问题，因为您的所有服务器都将被淹没！
但是如果您必须使用服务器本地会话状态，粘性会话绝对是要走的路——即使您不使用服务器本地会话状态，粘性在缓存利用率方面也有好处(见上文)).您的负载平衡器应该能够查看 HTTP cookie(不仅是 IP 地址)来确定粘性，因为 IP 地址可以在单个会话期间更改(例如，将笔记本电脑连接到有线和无线网络之间).
更好的是，根本不要在 Web 服务器上使用会话状态！如果会话状态丢失非常痛苦(例如购物车)，请将其存储在中央数据库中并定期清除旧会话.如果会话状态不重要(例如用户名/头像 URL)，则将其粘贴在 cookie 中——只需确保您没有将过多数据塞入 cookie.
由于上述原因，现代版本的 Rails 默认情况下将会话变量存储在 cookie 中.其他 Web 框架可能具有存储在 cookie"中.和/或存储在数据库中"选项.
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?
Pros:
- It's easy-- no app changes required.
- Better utilizes local RAM caches (e.g. look up user profile once, cache it, and can re-use it on subsequent visits from same user)
Cons:
- If the server goes down, session is lost. (note that this is a con of storing session info locally on the web server-- not of sticky sessions per se). if what's in the session is really important to the user (e.g. a draft email) or to the site (e.g. a shopping cart) then losing one of your servers can be very painful.
- Depending on "sticky" implementation in your load balancer, may direct unequal load to some servers vs. others
- ringing a new server online doesn't immediately give the new server lots of load-- if you have a dynamic load-balancing system to deal with spikes, stickiness may slow your ability to respond quickly to a spike. That said, this is somewhat of a corner case and really only applies to very large and sophisticated sites.
- If you have relatively few users but a single user's traffic can swamp one server (e.g. complex pages with SSL, AJAX, dynamically-generated images, dynamic compression, etc.), then stickines may hurt end-user response time since you're not spreading a single user's load evenly across servers. If you have a lot of concurrent users, this is a non-issue since all your servers will be swamped!
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).
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.
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屋！
