有很多与我的问题相关的类似问题。但我没有为我的问题找到任何令人满意的答案。所以我把这个问题放在这个论坛上。
我对库存管理系统中的并发控制有疑问。 假设我有数量为 2、3、4 的产品 A、B、C。我的应用程序是多用户的。
我有产品页面，用户可以在其中查看产品列表和可用数量。 我有结帐和付款页面，在产品页面之后可能需要一些时间才能到达。
现在，如果它是多用户 Web 应用程序，假设用户 1 订购了 2 个数量的产品 A，但尚未下订单，那么用户 2 仍然可以看到有 2 个数量的 A。
我应该暂时（可配置时间）锁定2个产品A的数量直到下订单吗？是不是很好的设计。如果是，我应该锁定java还是数据库？
【问题讨论】：
标签： java concurrency inventory
我应该暂时（可配置时间）锁定2个产品A的数量直到下订单吗？是不是很好的设计。
这取决于您网站的对话率，即结账次数/付款次数。如果您的会话率较高，您可以预先锁定数量以获得更好的用户体验。
如果是，我应该锁定java还是数据库？
你需要一个全局锁来保证正确性。如果你有多个应用服务器，你必须把锁放在数据库中。
【讨论】：
不，这不是一个好的设计，因为它会导致滥用和问题。如果用户（竞争对手？）在整个月内锁定了您的所有产品怎么办？如果另一个人在他/她的购物车里装满了产品，然后觉得钱太多，就关掉了他/她的设备怎么办？
最好的选择是：
1) 告诉用户每种产品的可用性，但也告诉他/她如果没有尽快下订单，它可能会消失。这也应该激励销售。在付款页面后锁定/解锁您的产品，即当有业务承诺时。如果可用数量不再足够，请将用户返回上一页，将数量更新为可用的数量。
2) 类似于 1)，但您也可以不时更新可用性。或发送警告，例如“您购物车中某些商品的库存不足”。同样，这也可以促进销售。
3) 将物品移至购物车时保留（“锁定”）物品，但不会永久保留。锁定一定时间后释放物品。随时通知用户。超时时间可以是整个购物车或每件商品。
请务必注意，上面提到的任何“锁定”都是“业务锁定/保留”。它不需要以锁或任何其他特定技术方案的形式实现。例如上面的3）可以通过添加字段locked_by和locked_until来实现。当您检查/更新/操作这些字段时，您可能需要在“技术锁”内进行。检查/更新完成后，技术锁被释放。但是，“业务锁定”可能仍然存在，因为 locked_until 尚未过期，并且任何其他代码将检查此字段以考虑产品是否可用。为什么？因为业务规则要求如此（不是因为存在技术锁定，实际上没有）。
“技术锁”应该很快。 “业务锁定”可以更长（但永远不会永远；始终为它们定义时间限制）。
您提供的信息很少，很难判断您是否应该在“数据库中”锁定“在 Java 中”。例如，您是否使用实体 Bean？您的容错要求是什么？等等。
也就是说，在一般情况下，最好在数据库中保留锁（只要它们是“业务锁”），主要原因如下：
【讨论】：
库存管理应由从头开始构建的自定义系统处理。出于性能原因，您不能仅仅依赖 ACID 合规性。在订单期间实施库存交易是一个非常糟糕的主意，并且不可扩展。我提出以下解决方案。
因此，在订单完成之前，您不会锁定产品行。相反，如果由于异常/应用程序故障导致订单不成功或失败，您会对库存进行软锁定并释放。
【讨论】：