库存控制的并发控制

Question

我的问题有很多类似的问题。但我没有找到任何令人满意的问题。所以我把这个问题放在这个论坛上。

我对库存管理系统中的并发控制存在疑问。 假设我有产品A，B，C，数量为2,3,4。我的应用程序是多用户。

我有产品页面，用户可以看到产品列表和可用数量。 我有退房和付款页面，可能需要一些时间才能到达产品页面后。

现在，如果它是多用户Web应用程序，并且说用户1订购了2个数量产品A但订单尚未下达，则用户2仍然可以看到有2个数量的A.

我应暂时（可配置的时间）锁定2个数量的产品A，直到下订单为止？这是一个很好的设计。如果是，我应该锁定java还是数据库？

Answer 1

不，这不是一个好的设计，因为它有助于滥用和解决问题。如果用户（竞争对手？）在整个月内锁定了您的所有产品，该怎么办？如果另一个人用产品填满他/她的购物车然后决定它太多钱并且只是关掉他/她的设备怎么办？

最佳选择是：

1）告诉用户每种产品的可用性有多少，但也告诉他/她如果没有尽快下订单，它可能会消失。这也应该激励销售。在付款页面之后锁定/解锁您的产品，即当业务提交操作时。如果可用数量不再足够，请将用户返回上一页，将金额更新为可用数量。

2）与1）类似，但您也可以不时更新可用性。或者发送警告，例如“购物车中某些商品的库存量不足”。同样，这也可能促使销售。

3）保留（“锁定”）物品，因为它们被移动到购物车，但不是永远。锁定一段时间后释放物品。随时通知用户。超时可以是整个购物车或每件商品。

注意上面提到的任何“锁定”都是“商业锁定/预订”是非常重要的。它不需要以锁的形式或任何其他特定的技术解决方案来实现。例如，可以通过添加字段locked_by和locked_until来实现上述3）。在检查/更新/操作这些字段时，您可能需要在“技术锁定”中执行此操作。检查/更新完成后，将释放技术锁。但是，“业务锁定”仍然存在，因为locked_until尚未过去，任何其他代码都会检查此字段以考虑产品是否可用。为什么？因为业务规则要求如此（不是因为存在技术锁定，实际上并非如此）。

“技术锁”应该非常快。 “商业锁”可能会更长（但永远不会永远;总是为它们定义时间限制）。

很难说你是否应该使用你提供的极少信息锁定“在数据库中”的“Java”。例如，您使用的是Entity Beans吗？您的容错要求是什么？等

那就是说，在一般情况下，最好是在数据库中保留锁（只要它们是“业务锁”），主要原因如下：

• 持久性（在电源故障的情况下）。您还应该提供恢复购物车的机制。也许还将它们存储在DB中？
• 能够与其他环境（即企业ERP或完整填充系统）进行交互。

Answer 2

  

我应暂时（可配置的时间）锁定2个数量的产品A，直到下订单为止？这是一个很好的设计。

这取决于您网站的通话率，即结帐次数/付款次数。如果您的会话率很高，则可以预先锁定数量以获得更好的用户体验。

  

如果是，我应该锁定java还是数据库？

您需要全局锁定才能保证正确性。如果您有多个应用程序服务器，则必须将锁定放在数据库中。

Answer 3

库存管理应由重新构建的自定义系统处理。出于性能原因，您不能仅依赖ACID合规性。在订单期间在库存上实施交易是一个非常糟糕的主意，并且不能扩展。我提出以下解决方案。

1. 库存管理后端应用程序，用于在新物品进入时更新库存。使用行锁来更新库存。
2. 库存管理微服务应用程序，用于将库存交给订单管理系统，因为它需要库存来完成订单并跟踪超时。 一种。如果订单以确认完成，则给定的库存已被管理系统扣除。我们很好。 b。如果订单未完成且未收到确认，则在超时（通常为2至3分钟）后，给定的库存将添加回库存系统。 C。如果订单失败，并且收到订单失败的确认，则将给定的库存添加回库存系统。

因此，在完成订单之前，您不会锁定产品行。相反，您可以对库存进行软锁定并在订单因异常/应用故障而失败或失败的情况下释放。