粘滞会话：好还是坏？

我有一个Web应用程序，当一个相同的请求发送到我的两个负载平衡服务器时，似乎有间歇竞争条件。很明显，在这一点上既没有完成交易，所以每个服务器上的两个操作都是有效的。粘滞会话：好还是坏？

会议粘稠会解决这个问题？是否使用粘性会议皱起了眉头？还有什么可能是一些其他解决方案？

我现在在亚马逊使用他们的负载平衡器托管。

来源

2011-11-21 Khalid Abuhakmeh

如果一个请求被发送到负载均衡的服务器集合中，则只有一个服务器应该得到请求，通常通过循环法进行分配。如果你正在发出一个请求，并且它碰到了你的服务器，那么别的东西是错误的。

否则我会假设你发出2个快速请求，并且他们碰到了你的两个负载平衡服务器（如循环赛），你的交易在第二个请求到达服务器之前没有完成，并且你认为粘性会话会解决这个问题。

粘滞会话会将此会话中的所有请求发送到同一台服务器。在你的例子中，两个请求现在都会碰到同一个服务器，如果你什么都没做，第一个请求的事务就不会在第二个请求开始之前被提交，所以你会得到相同的结果，即粘性会话本身就没有帮助。

如果交易类似于下订单，那么您可以制作您的代码，以便在成功提交后，购物车的内容被删除。完成的第一个请求会删除购物车，第二个请求会失败，并且您可以向用户发出订单已被放置的消息。

粘滞会话可能使其具有高可用性和可伸缩性变得更加复杂。对于前者，请考虑一台服务器故障的情况 - 该服务器上的所有会话都将停机，您将不得不编写代码使其无法通过另一台服务器。

对于后一种情况，假设您的会话持续一段时间，例如半小时，如果您有N位新用户访问该网站，他们最初将在您的两台服务器之间平均分配。如果在1/2小时之前，所有来自服务器1的用户都离开并且另一个M用户进来，那么您将在具有原始N/2用户加上新的M/2用户的服务器2上承担更多负载，而服务器1仅具有M/2个用户，即您将浪费容量并需要编码进行修复。

有些时候，粘性会话可能是有用的，但除非你有很好的理由来使用他们，我会避开他们

来源

2011-11-21 16:31:07

是两个请求迅速传送到负载均衡器，遗憾的是目前还不清楚。似乎我需要一种完全不依赖数据库中状态的方式，可能是内存中目标的缓存版本。 –

粘滞会话：好还是坏？

回答

相关问题