gpt4 book ai didi

java - 微服务 - 多个服务副本之间的竞争条件

转载 作者:行者123 更新时间:2023-12-04 07:41:20 25 4
gpt4 key购买 nike

我现在正在学习微服务 - Spring Cloud。在研究过程中,我在思考以下几种情况下如何处理race condition。
假设我有一个“ProductOrder”服务,它有 2 个副本。现在有两个订单请求,负载均衡器为每个副本分配一个 api 请求。请注意,它们共享同一个数据库(所以我不是在谈论数据同步。或者我是?)。那么该服务如何确保存储仍然有足够的产品来满足订购要求。
我知道 Java 中的关键字“同步”是用于多线程的。但是,副本不是多线程而是多进程。我对么?有任何想法吗?

最佳答案

数据库将有一个表,如 Product(id, amount) .下订单将需要更新该产品的记录。
它的实现看起来像这样。首先,应用程序将从数据库中读取产品数量:

SELECT id, amount
FROM Product
WHERE id = {some_id}
FOR UPDATE;
然后应用程序代码将检查是否有请求的金额。然后它将更新数据库中的值:
UPDATE Product
SET amount = {new_amount}
WHERE id = {some_id}
注意:
  • 所有这些都应该发生在一个数据库事务中
  • 第一个查询使用 FOR UPDATE条款以防止其他并发事务在我们的事务运行时修改此产品。把它想象成一个 synchronized但不是在 JVM 级别,而是在 DB 级别。
  • 如果另一个用户将尝试购买相同的产品,该用户的交易(我们称之为 T2)将尝试做同样的事情,第一步是查询带锁的记录。这将阻塞事务 T2 直到记录被解除阻塞,并且当当前持有锁的事务提交或回滚时就会发生这种情况。届时,T2 将继续进行,如果产品被 T1 更改,它将看到产品的最新值。

  • 这种方法使用悲观锁,即我们在整个事务期间锁定要更新的记录。
    还有另一种方法——乐观。
    乐观锁要求您在产品表中有一个版本列。然后第一个查询不会锁定数据库中的记录,但我们得到了记录的版本:
    SELECT id, amount, version
    FROM Product
    WHERE id = {some_id}
    checkin 应用程序的工作方式与悲观场景中的方式相同。但最终的更新是不同的:
    UPDATE Product
    SET amount = {new_amount}
    WHERE id = {some_id}
    and version = {version_we_read_initially}
    更新操作总是返回更新记录的数量。如果我们得到 0,则表示在我们的事务运行时记录已更改。这意味着我们最初看到的金额(在第一个查询中)可能已更改。为了继续,我们需要重试从步骤 1 开始的整个操作,即再次读取产品的数量和版本,检查是否有所需数量并再次尝试更新数量。
    当然,我们要重试的次数应该有一些限制。在需要产品的繁忙系统上,这可能会成为一个问题。

    关于java - 微服务 - 多个服务副本之间的竞争条件,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/67445195/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com