REST API：如何避免服务器端读-更新-写循环中的竞态问题

假设我们有一个基于关系型数据库的API。已知可以用乐观并发控制（比如版本字段）避免客户端读/更新/写循环时的更新丢失，但现在考虑客户端发送PATCH请求的场景：客户端不需要预先知道资源详情（只需要ID），只发送待更新的数据（比如JSON patch格式）。

举个具体例子：资源有一个指纹集合字段，每个客户端要把自身指纹添加到集合里，不能删除现有指纹。请求处理顺序无所谓，但必须保证所有请求都不丢失，否则部分客户端的指纹存不进去。

服务器收到请求后，要完成「读取资源（验证存在+获取待合并字段值）→ 应用变更 → 写回结果」的流程，全程不需要客户端参与。但这个序列有竞态问题：多个客户端同时PATCH同一资源的同个字段时，很容易出现更新丢失。

我想到了几种解决策略：

• 悲观并发控制：操作全程用SELECT .. FOR UPDATE给资源加数据库锁
• 内部乐观并发控制：读取资源后，写回时检查期间是否被修改；如果已修改，要么终止让客户端重试，要么基于新版本自动重试（设重试次数上限）
• 异步串行处理：把所有请求发进队列，按接收顺序串行执行，但没法给客户端实时反馈

想知道：我有没有遗漏其他策略？还有哪些补充方案？这些方法在实际生产中是否被采用？

你提到的三种策略都是生产中常用的方案，除此之外还有以下几种实用思路：

1. 数据库层面的原子更新操作 #

利用关系型数据库的原子性语句直接完成合并逻辑，跳过「读-改-写」的分步操作，从根源避免竞态。比如针对指纹集合的场景：

• 如果用PostgreSQL，可以用UPDATE table SET fingerprints = fingerprints || 'new_fingerprint' WHERE id = ?（数组类型字段的原子追加）
• 如果是MySQL，可以用UPDATE table SET fingerprints = CONCAT(fingerprints, ',new_fingerprint') WHERE id = ?（字符串拼接，注意要处理空值情况）
  这种方式完全依赖数据库的事务原子性，不需要额外锁或重试，性能和可靠性都很高，是这类场景的首选方案，生产中大量使用。

2. 分布式锁（跨服务场景） #

如果你的API是分布式部署的，单数据库锁可能覆盖不到跨节点的并发请求，可以用Redis或ZooKeeper实现分布式锁：

• 客户端请求到达后，先获取对应资源ID的分布式锁（带超时时间，避免死锁）
• 拿到锁后再执行「读-改-写」流程
• 操作完成后释放锁
  这种方案适合跨实例的并发控制，但要注意锁的超时时间设置、锁释放的正确性（比如用Lua脚本保证原子释放），生产中在分布式系统里很常见。

3. 幂等性设计+最终一致性 #

如果业务允许短暂的不一致，且能接受最终一致，可以结合幂等性和异步重试：

• 给每个PATCH请求分配唯一的幂等ID，服务器记录已处理过的幂等ID，避免重复执行
• 执行「读-改-写」时如果出现冲突，直接将请求放入重试队列，后台异步重试，直到成功
• 客户端可以通过查询接口获取最终状态
  这种方案适合对实时性要求不高，但要求100%不丢失请求的场景，比如日志上报、批量数据更新等。

各方案的生产实践情况 #

• 原子更新操作：最推荐，只要数据库支持对应的原子语法，几乎是首选，比如电商的库存扣减、用户标签追加都用这种方式。
• 悲观锁（SELECT FOR UPDATE）：适合并发量不高、业务逻辑复杂（无法用单条SQL实现）的场景，比如订单状态流转，但要注意锁的粒度，避免锁表导致性能问题。
• 内部乐观重试：适合并发量中等、业务逻辑复杂的场景，比如CRM系统的客户信息更新，生产中通常会设置3-5次的重试上限，避免无限阻塞。
• 异步串行队列：适合并发量极高，但实时性要求低的场景，比如用户行为数据的批量合并，生产中常用RabbitMQ、Kafka这类消息队列实现。
• 分布式锁：适合分布式部署的API服务，比如微服务架构下的资源更新，但要注意锁的可靠性，避免出现锁泄露或死锁。

内容的提问来源于stack exchange，提问作者persson