Session 棘手的会议：好还是坏？

我有一个web应用程序，当一个相同的请求被发送到我的两个负载平衡服务器时，它似乎有间歇性的竞争条件。显然，此时两个服务器都没有完成事务，因此每个服务器上的两个操作都是有效的

粘性会话能否解决此问题？是否不赞成使用粘性会话？还有其他解决方案吗？

---

我现在正在Amazon上使用他们的负载平衡器托管。

如果一个请求被发送到负载平衡的服务器集，那么只有一个服务器应该得到该请求，通常通过循环分配。如果您发出一个请求，但它同时击中了两台服务器，那么其他一些问题就出现了

否则，我将假设您发出了2个快速请求，并且它们击中了两个负载平衡的服务器（正如循环赛一样），您的事务在第二个请求击中服务器之前没有完成，并且您认为粘性会话可以解决此问题

粘性会话将此会话中的所有请求发送到同一服务器。在您的示例中，两个请求现在都会命中同一台服务器，如果您不做任何其他操作，则第一个请求的事务在第二个请求启动之前不会提交，因此您将得到相同的结果，即仅粘性会话不会有帮助

如果事务类似于下订单，那么您可以手工编写代码，以便在成功提交时删除购物车的内容。 第一个完成请求将删除购物车，第二个请求将失败，您可以向用户发送消息，说明订单已经下好

粘性会话会使高可用性和可伸缩性变得更加复杂。对于前者，考虑一个服务器宕机的情况——服务器上的所有会话也会下降，您必须编写代码以使它们失效到另一个服务器。p> 对于后一种情况，假设您的会话持续一段时间，例如1/2小时，如果您有N个新用户访问该站点，那么他们最初将在两台服务器之间平均分配。如果在1/2小时之前，服务器1中的所有用户都离开了，而另一个M用户进来了，那么服务器2上的负载将更大，原来的N/2用户加上新的M/2用户，而serer 1只有M/2用户，即，您将浪费容量，并且需要编写代码进行修复

---

有时粘性会话可能有用，但除非您有充分的理由使用它们，否则我会避免使用它们

是的，两个请求会快速发送到负载平衡器，很抱歉不清楚。看起来我需要一种不完全依赖于数据库中状态的方法，可能是内存中目标的缓存版本。