如何让设置用户评分的Rest API方法实现幂等性？

你的核心需求是让接口重复调用（比如网络重试、用户重复提交）时，不会因为user_id+rate_id的复合主键冲突抛出异常，且最终结果一致。以下是几种实用的实现方式：

1. 用数据库UPSERT语句（推荐方案） #

直接利用数据库的原生原子操作，一步完成“不存在则插入，存在则更新”的逻辑，天然支持幂等性，无需额外的查询或异常捕获。

示例（MySQL） #

INSERT INTO user_rates (user_id, rate_id, score, updated_at)
VALUES (?, ?, ?, NOW())
ON DUPLICATE KEY UPDATE
  score = VALUES(score),
  updated_at = NOW()

• 当记录不存在时：执行插入操作，返回成功
• 当记录已存在时：
  • 如果传入的score和现有值相同，数据库不会实际修改数据（或仅更新updated_at，不影响业务结果），不会抛出异常
  • 如果传入的score不同，执行更新操作，覆盖原有值
• 优势：原子性强，避免并发冲突，无需额外代码处理异常，性能最优

示例（PostgreSQL） #

INSERT INTO user_rates (user_id, rate_id, score, updated_at)
VALUES ($1, $2, $3, NOW())
ON CONFLICT (user_id, rate_id) DO UPDATE SET
  score = EXCLUDED.score,
  updated_at = NOW()

2. 先查询后操作（需处理并发） #

如果无法使用UPSERT，可以先查询现有记录，再决定插入或更新：

• 开启数据库事务，查询时加行锁（避免并发插入冲突）：

  SELECT score FROM user_rates WHERE user_id = ? AND rate_id = ? FOR UPDATE;
  

• 根据查询结果处理：
  • 无记录：执行插入操作
  • 有记录：对比请求中的score和现有值
    • 相同：直接返回成功响应（无需修改）
    • 不同：执行更新操作
• 注意：必须加事务和行锁，否则高并发场景下可能出现两个请求同时查询无记录，然后都执行插入导致主键冲突。

3. 优化现有异常捕获逻辑（临时过渡方案） #

如果暂时不想修改核心数据库操作，可以调整异常处理逻辑，区分重复提交的场景：

• 捕获框架抛出的主键冲突异常（比如SQL的DuplicateEntry异常）
• 捕获异常后，立即查询该user_id+rate_id对应的现有评分
• 对比现有评分和请求中的评分：
  • 相同：返回成功响应（200或204）
  • 不同：返回409 Conflict响应，提示用户“评分已被修改”
• 劣势：需要多一次数据库查询，并发场景下可能出现逻辑不一致，不如UPSERT可靠

额外建议 #

• 接口响应统一：不管是首次提交还是重复提交相同评分，都返回相同的成功状态码（比如200 OK或204 No Content），避免客户端处理不一致的响应
• 若需严格幂等（比如防止不同请求用相同复合主键但不同评分的重复提交），可以要求客户端传递Idempotency-Key请求头，服务端缓存该键对应的请求结果，相同键直接返回缓存结果（需注意缓存过期策略）

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