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 回答