库存控制中的并发控制

Question

有许多类似的问题与我的问题有关。但对于我的问题，我没有找到满意的答案。所以我要在这个论坛上提出这个问题。

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

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

现在，如果它是多用户web应用程序，并且说用户1已经订购了2个数量的产品A，但是还没有下订单，用户2仍然可以看到有2个数量的A。

我应该暂时(可配置时间)锁定2批产品A直到下订单吗？这是个好设计吗。如果是，我应该锁定在java还是在数据库中？

Answer 1

不，这不是一个好的设计，因为它有助于滥用和问题。如果用户(竞争对手)呢？在整个月里锁上你所有的产品？如果另一个人在购物车里塞满了产品，然后决定要花太多的钱，而只是关掉了他/她的设备，该怎么办？

最佳替代办法是：

1)告诉用户每种产品的可用性有多大，但也告诉他/她，如果不马上下订单，它可能会消失。这也应该鼓励销售。请在付款页面后锁定/解锁您的产品，即当业务承诺操作时。如果可用的数量还不够，请将用户发回上一页，更新到轮询服务器的数量是可用的。

2)类似于1)，但您也可以不时地更新可用性。或者发送诸如“购物车中某些商品的库存正在减少”之类的警告。同样，这也可能促进销售。

3)保留(“锁”)物品，因为他们被移动到购物车，但不是永远。在锁定一定时间后释放这些物品。随时通知用户。超时时间可以按整个购物车或每件商品进行。

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

“技术锁”应该非常快。“业务锁”可能要长得多(但永远不会永远；总是为它们定义一个时间限制)。

很难判断您是否应该用所提供的非常少的信息锁定"in Java“上的"in the database”。例如，您正在使用实体Beans吗？您的容错要求是什么？等。

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

• 持久性(在电源故障时)。您还应该提供一个恢复购物车的机制。也许还会将它们存储在DB中？
• 能够与其他环境(如企业ERP或完整的系统)进行接口。

Answer 2

我应该暂时(可配置时间)锁定2批产品A直到下订单吗？这是个好设计吗。

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

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

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

Answer 3

库存管理应由从地面建立的自定义系统来处理。出于性能原因，不能简单地依赖ACID遵从性。在订单过程中在库存上实现事务是一个非常糟糕的想法，是不可伸缩的。我提出以下解决办法。

1. 一个库存管理后端应用程序，更新库存时，新的项目进来。使用行锁更新库存。
2. 一个库存管理微型服务应用程序，使库存到订单管理系统，因为它需要库存完成订单和跟踪的时间外。如果订单以确认方式完成，则已由管理系统扣除给定的库存。我们很好。b.如果订单未完成且未收到确认，则在超时后将给定的库存添加回库存系统(通常为2-3分钟)。如果订单失败，并且收到订单失败的确认，则将给定的库存添加到库存系统中。

因此，在订单完成之前，您不会锁定产品行。相反，如果订单由于异常/应用程序失败而不成功或失败，则对库存执行软锁并释放。