REST API：如何在服务器端执行读-更新-写周期时防止竞争

Question

我们假设一个关系数据库支持的 API。我了解乐观并发控制的用法（例如通过使用版本字段）来防止客户端更新丢失（其中 r/u/w 循环由客户端执行）。但是让我们想象一下客户端发送的 PATCH 请求；客户端不需要事先了解资源（或最少，例如仅 ID），只需发送数据进行更新（例如，以 JSON 补丁格式或其他格式）。

当它收到请求时，要应用补丁，服务器必须从后端读取资源（以查看它是否存在并获取需要合并/修补的任何值），应用请求的更改，并写回结果，一切都在服务器端进行，无需客户端参与。 不难看出，这样的操作序列是不安全的，如果多个客户端同时针对同一资源和字段发送 PATCH，很容易导致更新丢失。

如何预防这种情况？我可以想到一些策略：

• 在整个操作过程中对资源使用悲观锁定（即真正的数据库锁定）
• “在内部”使用乐观锁定，即获取资源并在写回时检查资源是否同时发生变化；如果确实如此，要么立即使操作失败（客户端必须重试或其他方式），要么使用新版本的资源重试，依此类推（可能最多固定次数）直到成功。

我这里缺少什么吗？还有其他策略吗？

Answer 1

我这里缺少什么吗？还有其他策略吗？

YOLO算作额外策略吗？

据我所知，如果您有并行处理的请求，并且它们之间没有协调，并且您想要类似“第一个写入者获胜”语义的东西，那么在一般情况下，您需要锁定或者需要比较 -由持久存储提供的 and-swap 语义。

（这个约束没有什么特别的 HTTP/REST，它只是世界的物理现象。）

---

如果您记下内容的顺序并不重要，您也许可以在不锁定的情况下逃脱。 无冲突的复制数据类型或您可以将信息视为更改的集而不是更改的序列的情况，并且任何查看同一组更改的人都会收敛于相同的“状态”。