4

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

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

我有产品页面，用户可以在其中看到产品列表和可用数量。我有结帐和付款页面，在产品页面之后可能需要一些时间才能到达。

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

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

4

3 回答 3

5

不，这不是一个好的设计，因为它很容易导致滥用和问题。如果用户（竞争对手？）在整个月内锁定了您的所有产品怎么办？如果另一个人在他/她的购物车里装满了产品，然后觉得钱太多，就关掉了他/她的设备怎么办？

最好的选择是：

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

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

3) 在物品被移动到购物车时保留（“锁定”）物品，但不是永远。锁定一定时间后释放物品。随时通知用户。超时可以是整个购物车或每个项目。

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

“技术锁”应该很快。“业务锁”可以更长（但永远不会永远；总是为它们定义时间限制）。

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

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

  • 持久性（在电源故障的情况下）。您还应该提供一种恢复购物车的机制。也许还将它们存储在数据库中？
  • 与其他环境（即企业 ERP 或完整系统）交互的能力。
于 2013-08-18T03:19:38.527 回答
1

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

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

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

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

于 2013-08-18T03:19:24.350 回答
0

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

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

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

于 2019-12-12T17:08:05.427 回答