Session 粘性会话/会话关联负载均衡策略的利弊？

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

这种方法带来的一个挑战是服务器是状态感知的——将用户状态存储在“会话”中

这个问题的一个解决方案是“粘性会话”（也称为“会话亲和力”），其中每个用户被分配到单个服务器，并且在会话期间，他/她的状态数据只包含在该服务器上

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

优点：

• 这很简单——不需要更改应用程序
• 更好地利用本地RAM缓存（例如，查找用户配置文件一次，缓存它，并可在同一用户的后续访问中重新使用）

缺点：

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

但是，如果必须使用服务器本地会话状态，粘性会话肯定是一种方法——即使不使用服务器本地会话状态，粘性在缓存利用率方面也有好处（见上文）。您的负载平衡器应该能够查看HTTP Cookie（不仅仅是IP地址）以确定粘性，因为IP地址在单个会话期间可能会发生变化（例如，将笔记本电脑停靠在有线和无线网络之间）

更好的是，根本不在web服务器上使用会话状态！如果会话状态很难丢失（例如购物车），请将其存储在中央数据库中，并定期清除旧会话。如果会话状态不是关键状态（例如用户名/化身URL），则将其粘贴到cookie中——只需确保没有将太多数据塞进cookie中即可

---

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

好的anwsers！请您再解释一下“您的负载平衡器应该能够查看HTTP Cookie（不仅仅是IP地址）”，这是什么意思？负载平衡器如何知道它是否是同一个用户？Web应用通常会向客户端发送cookie，以便当客户端返回另一个HTTP请求时，服务器可以识别相同的用户或会话。一些负载平衡器可以查看HTTP cookie标头以识别用户，并可以使用该cookie值而不是IP地址来确定哪个服务器应接收该请求。如果我将状态存储在db/memcache中，我是否可以认为该应用程序是无状态的，而有些人会说，要制作无状态的应用程序，我们必须保持客户端的状态。@jaskey-这是一个好问题，我建议您为此打开一个新问题。是的，请您在这里回答：