如何处理 Web 应用程序中的并发更改？

Question

以下是我想在 Web 应用程序中执行的两个潜在工作流程。

变体 1

• 用户发送请求
• 服务器读取数据
• 服务器修改数据
• 服务器保存修改后的数据

变体 2：

• 用户发送请求
• 服务器读取数据
• 服务器向用户发送数据
• 用户发送带有修改的请求
• 服务器保存修改后的数据

在每种情况下，我想知道：什么是确保对该服务的并发访问将产生合理结果的标准方法？ （即没有人的编辑被破坏，值对应于编辑的某些顺序等）

这种情况是假设的，但这里有一些我在实践中可能需要处理这个问题的细节：

• Web应用程序，但
• 可能未指定语言，使用Web框架
• 数据存储是一个SQL关系数据库，
• 涉及的逻辑太复杂，无法在查询中很好地表达，例如值=值+1

我觉得我不想在这里尝试重新发明轮子。当然，这些都是众所周知的问题，也有众所周知的解决方案。请指教。

谢谢。

Answer 1

据我所知，这个问题没有通用的解决方案。

问题的根源在于，用户可能会检索数据并在屏幕上盯着它很长时间，然后再进行更新和保存。

我知道三种基本方法：

1. 当用户读取数据库时，锁定记录，直到用户保存任何更新后才释放记录。实际上，这是非常不切实际的。如果用户打开一个屏幕然后去吃午饭而不保存怎么办？还是回家休息一天？或者在尝试更新这个愚蠢的记录时感到非常沮丧，以至于他退出并且再也没有回来？

2. 将您的更新表示为增量而不是目的地。举一个经典的例子，假设您有一个记录库存的系统。每次有销售时，您都必须从库存数量中减去 1（或更多）。

假设现有数量为 10。用户 A 创建了一笔销售。当前数量 = 10。用户 B 创建销售。他还得到当前数量 = 10。用户 A 输入已售出两个单位。新数量 = 10 - 2 = 8。保存。用户 B 输入已售出的一件商品。新数量 = 10（他加载的值） - 1 = 9。保存。显然，出了问题。

解决方案：不要编写“更新库存集数量=9，其中 itemid=12345”，而是编写“更新库存集数量=数量-1，其中 itemid=12345”。然后让数据库对更新进行排队。这与策略 #1 有很大不同，因为数据库只需锁定记录足够长的时间即可读取、更新和写入。当有人盯着屏幕时，它不必等待。

当然，这仅适用于可以表示为增量的更改。比如说，如果您要更新客户的电话号码，这是行不通的。 （例如，旧号码是 555-1234。用户 A 说将其更改为 555-1235。这是 +1 的更改。用户 B 说将其更改为 555-1243。这是 +9 的更改。所以总更改是+10，客户的新号码是 555-1244 :-) ) 但在这种情况下，“最后一个单击 Enter 键的用户获胜”是。无论如何，这可能是你能做的最好的事情。

1. 更新时，检查数据库中的相关字段是否与您的“来自”值匹配。例如，假设您在一家律师事务所工作，为您的客户谈判合同。您有一个屏幕，用户可以在其中输入有关谈判的注释。用户A调出一条合同记录。用户B调出相同的合同记录。用户 A 输入，他刚刚通过电话与另一方通话，并且他们同意所提议的条款。用户 B 也一直试图给对方打电话，他输入说他们没有回复电话，他怀疑他们在阻挠。用户 A 单击“保存”。我们是否希望用户 B 的评论覆盖用户 A 的评论？可能不会。相反，我们显示一条消息，指示自他读取记录以来注释已更改，并允许他在决定是否继续保存、中止或输入不同内容之前查看新值。

[注意：论坛会自动对我的编号列表重新编号。我不知道如何覆盖这个。]

Answer 2

来回答一下标题中的问题。有两种通用解决方案可用于处理通过 HTTP 丢失更新问题 。

假设您的应用程序由两个组件组成；一个前端和一个 API 后端。并且有两个并发用户尝试对同一数据执行更新。

1. 乐观并发控制

实现某种方式来了解哪些数据最后更新了。一些常见的方法：

• 使用 ETag。这可以是存储在数据库中的字段，但也可以在每次更新时计算。
• 使用存储在 db 中的 LastUpdated 时间戳字段
• 使用存储在 db 中的 Version 字段

上面提到的方式可以与使用 条件 HTTP 标头。如果您的服务器框架开箱即用地支持它，那么它会很有用。

示例：

1. 用户 1 发出 GET 请求。用户 2 发出相同的 GET 请求并检索相同的数据。
2. 用户 2 在 PUT 请求中更新数据。
3. 用户 1 发出 PUT 请求并收到错误消息。这是因为 API 后端比较了传入数据（来自用户 1）的 ETag 和 db 中数据（来自用户 2）的 ETag，但 ETag 不匹配。这意味着我们知道用户 1 在发送 PUT 请求时没有最新的更改。

2. 悲观并发控制

使用（悲观）数据库锁。

示例：用户 1 发出 GET 请求。用户 2 发出相同的 GET 请求并收到错误。这是因为我们无法给出可能过时的数据，因此该信息已被数据库锁定。

这种方法有很大的缺点。

• 用户2长时间无法读取或更新该数据。而用户1甚至还没有进行更新。
• 另一种方法是使用数据库事务。 GET 请求开始一个事务，并在用户发出 POST 请求或离开站点时结束。这可以允许更多的并发性。
• 悲观并发控制要求 API 后端知道用户 1 何时不再查看前端的某些数据。这很难。通信可能通过无状态的 HTTP 进行。如果我猜测一个解决方案，可能是使用 Websockets 与用户 1 保持有状态连接，以监视她正在查看和编辑哪些数据。 （当然也有缺点）

更改 API

人们可以更改 API，这样就不会出现更新丢失的问题。

@jay 已经提到增量更新作为解决方案。假设模型中有一个数字字段，每次请求时该字段应加 1。一种实现是 PUT 端点，它使用传入的号码更新模型和字段。该API存在更新丢失问题。另一种实现是有一个增量端点。该API不存在更新丢失的问题。 （如果您将增量视为资源并使用 POST 创建新增量，则该 API 是 RESTful）。

另一种方法是将 API 从 PUT 更改为 PATCH。这不是一个解决方案，但它可以最大限度地减少丢失更新的可能性。

结论

使用乐观并发控制。

当谷歌搜索“丢失更新问题”时，可能只能得到有关数据库的结果。尽管这是同样的问题，但数据库锁定对于通过 HTTP 丢失并发更新来说并不是一个好的解决方案。如上所述，与乐观并发控制相比，它有几个缺点。

Answer 3

如果mysql中没有事务，可以使用update命令来确保数据没有损坏。

UPDATE tableA  SET status=2  WHERE status = 1

如果状态为一，则只有一个进程可以得到记录已更新的结果。在下面的代码中，如果未执行更新（如果没有要更新的行），则返回 -1。

PreparedStatement query;
query = connection.prepareStatement(s);
int rows = -1;
try
{
    rows = query.executeUpdate();
    query.close();
}
catch (Exception e)
{
   e.printStackTrace();
}
return rows;

Answer 4

应用程序层中的事情很简单 - 每个请求都由不同的线程（或进程）提供服务，因此除非您的处理类（服务）中有状态，否则一切都是安全的。

当您到达数据库（即保存状态的位置）时，事情会变得更加复杂。您需要事务来确保一切正常。

事务具有一组属性 - ACID，“保证数据库事务得到可靠处理”。