如何在负载平衡的服务器上处理多个更新请求

Question

我有一个客户端应用程序，它将项目添加到购物车。 “添加”操作通过HTTP REST调用向远程端点发出更新请求。请注意：此请求包含完整购物车作为一个整体，而不仅仅是要添加的项目。然后使用循环算法在两台服务器之间对此请求进行负载平衡。

我试图解决的问题是，如果用户这样做，客户端不会等待“添加”请求返回之前再启动另一个“添加”请求。从最终用户的角度来看这很好，因为用户不必等待。但从服务器的角度来看，这是一场噩梦：由于负载均衡器，您无法确定处理请求的顺序。

以下是一个例子：

• 用户将商品＃1添加到购物车。请求A已发送。
• 用户将项目＃2添加到购物车。请求B被发送。请注意，请求B在请求A收到响应之前发送。
• 请求A在服务器1上进行负载平衡，请求B在服务器2上进行负载平衡
• 由于某些原因，服务器1比服务器2慢，因此首先处理请求B =＆gt;购物车有第1项和第2项
• 服务器1处理请求A =＆gt;购物车只有＃1项（提醒：每个更新请求包含购物车）

我不太确定如何处理这个问题。到目前为止，我能想到的可能的解决方案是：

• 发送带有请求的时间戳并将时间戳保留在数据库中。在更新购物车之前，请检查请求的时间戳是否更高。否则请删除请求。但这很大程度上依赖于客户端行为。
• 在购物车上设置版本号，并在每次更新时递增。这会强制客户端在发送另一个更新之前等待响应。从最终用户的角度来看并不十分令人满意，因为他必须等待。
• 在负载均衡器上设置“会话亲缘关系”，以便每次将来自特定客户端的请求通过管道传送到同一服务器。问题是它会影响服务器负载的平衡。

我很确定我不是第一个面对这个问题的人，但我很难找到类似的案例，这令人惊讶。我一定要问错了问题或关键词！无论如何，我很想分享你对这个问题的想法和经验。

Answer 1

最简单的方法是发送操作详细信息（添加＃1，添加＃2 ...），以便能够在服务器上以增量方式重建购物车。有了这些信息，您根本不会依赖于按特定顺序处理的请求。

如果您无法修改API，那么您的第三个解决方案（在整个持续时间内在同一服务器上处理相同的会话）可能是要走的路，而无需按客户/客户数量提供有关预期负载的更多信息。