想象一下,您正在开发一个电子商务系统,成千上万的人试图同时购买最后剩下的产品。然而,他们中的许多人可以继续结账并完成订单。当您检查库存时,您的产品数量为负数。这是怎么可能的,你该如何解决这个问题?
让我们编码吧!您可能想到的第一件事是在结帐前检查库存。也许是这样的:
public void validateAndDecreaseSolution(long productId, int quantity { OptionalstockByProductId = stockRepository.findStockByProductId(productId); int stock = stockByProductId.orElseThrow().getStock(); int possibleStock = stock - quantity; if (stock 您可以使用此验证,但是当我们谈论每秒数百、数千、数百万甚至数十个请求时,此验证是不够的。当 10 个请求同时到达这段代码并且数据库为 stockByProductId 返回相同的值时,您的代码将崩溃。在我们进行此验证时,您需要一种方法来阻止其他请求。
第一个解决方案 - 用于更新
在 SELECT 上添加锁定语句。在此示例中,我使用 Spring Data 的 FOR UPDATE 来完成此操作。正如 PostgreSQL 文档所述
FOR UPDATE 导致 SELECT 语句检索的行被锁定,就像要进行更新一样。这可以防止它们被其他事务修改或删除,直到当前事务结束。
@Query(value = "SELECT * FROM stocks s WHERE s.product_id = ?1 FOR UPDATE", nativeQuery = true) OptionalfindStockByProductIdWithLock(Long productId); public void validateAndDecreaseSolution1(long productId, int quantity) { OptionalstockByProductId = stockRepository.findStockByProductIdWithLock(productId); // ... validate stockRepository.decreaseStock(productId, quantity); } 所有使用产品ID对stocks表的请求都将等待,直到实际事务完成。这里的目标是确保您获得股票的最新更新价值。
第二种解决方案 - pg_advisory_xact_lock
此解决方案与上一个类似,但您可以选择锁定键是什么。我们将锁定整个交易,直到完成所有验证和库存减量的处理。
public void acquireLockAndDecreaseSolution2(long productId, int quantity) { Query nativeQuery = entityManager.createNativeQuery("select pg_advisory_xact_lock(:lockId)"); nativeQuery.setParameter("lockId", productId); nativeQuery.getSingleResult(); OptionalstockByProductId = stockRepository.findStockByProductId(productId); // check stock and throws exception if it is necessary stockRepository.decreaseStock(productId, quantity); } 本次交易结束后,下一次请求只会与同ID的商品进行交互。
第三种解决方案 - WHERE 子句
在这种情况下,我们不会锁定行或事务。让我们允许此事务继续进行,直到更新语句为止。请注意最后一个条件:库存 > 0。这将不允许我们的库存小于零。因此,如果两个人尝试同时购买,其中一个人会收到错误,因为我们的数据库不允许库存
@Transactional @Modifying @Query(nativeQuery = true, value = "UPDATE stocks SET stock = stock - :quantity WHERE product_id = :productId AND stock > 0") int decreaseStockWhereQuantityGreaterThanZero(@Param("productId") Long productId, @Param("quantity") int quantity);结论
第一个和第二个解决方案使用悲观锁定作为策略。第三是乐观锁。当您在执行涉及某个资源的任何任务时希望限制对该资源的访问时,可以使用悲观锁定策略。在您完成进程之前,目标资源将被锁定以进行任何其他访问。小心死锁!
使用乐观锁,您可以对同一资源执行各种查询,而不会出现任何阻塞。当冲突不太可能发生时使用它。通常,您会有一个与您的行相关的版本,当您更新该行时,数据库会将您的行版本与数据库中的行版本进行比较。如果两者相等,则更改将成功。如果没有,您必须重试。正如您所看到的,我在本文中没有使用任何版本行,但我的第三个解决方案不会阻止任何请求并使用 stock > 0 条件控制并发性。
如果你想看完整的代码,可以查看我的GitHub。
还有很多其他策略来实现悲观锁定和乐观锁定,例如您可以搜索更多有关 FOR UPDATE WITH SKIP LOCKED 的内容。
免责声明: 提供的所有资源部分来自互联网,如果有侵犯您的版权或其他权益,请说明详细缘由并提供版权或权益证明然后发到邮箱:[email protected] 我们会第一时间内为您处理。
Copyright© 2022 湘ICP备2022001581号-3