所有涉及数据变更的接口，都一定要做幂等处理吗？

最新推荐文章于 2025-11-27 17:11:16 发布

原创最新推荐文章于 2025-11-27 17:11:16 发布 · 604 阅读

11 ·

CC 4.0 BY-SA版权

文章标签：

#java

一个状态同步的接口，如 “将审批单状态同步到 OA 系统”，即使重复同步，目标系统可通过 “审批单 ID + 当前状态” 判断是否需要更新，重复调用不会产生异常状态。

前言

大家好，我是田螺。

最近面试了一位Java开发候选人，10年的开发经验，居然不知道接口幂等如何设计。。。

我们本文来聊聊，后端设计的一个重要原则：接口幂等性。以及什么样的接口才做幂等处理。

是否所有的接口都必须进行幂等处理呢？是否所有涉及数据变更的接口，都要做幂等处理呢？

显然不是，我们要综合考虑业务场景、数据重要程度、数据修复难易程度等，灵活判断是否需要幂等设计，避免过度设计！

什么是接口幂等性？
哪些接口必须做幂等处理
哪些接口可酌情不做幂等处理
通用方案：如何设计幂等接口？
幂等涉及的分布式唯一ID如何生成
幂等设计的核心原则

1. 什么是接口幂等性？

幂等是一个数学与计算机科学概念。

在数学中，幂等用函数表达式就是：f(x) = f(f(x))。比如求绝对值的函数，就是幂等的，abs(x) = abs(abs(x))。
计算机科学中，幂等表示一次和多次请求某一个资源应该具有同样的副作用，或者说，多次请求所产生的影响与一次请求执行的影响效果相同。

比如说，你调用下游接口做转账，然后接口网络超时了（实际下游转账成功了），然后你用原来的流水号发起重试，如果下游接口不做幂等处理，那就会导致重复支付！

2. 哪些接口必须做幂等处理

判断接口是否需要幂等处理，核心标准是 “重复调用是否会造成业务损失或数据异常”。一般资金交易、订单相关等接口，都要实现幂等性，比如：

支付接口：如用户下单支付、退款、转账等接口。若未做幂等，用户重复发起支付请求，可能导致多笔扣款，引发严重的资金纠纷和用户信任危机。
订单创建接口：若用户因网络延迟重复提交订单，未做幂等会生成多个重复订单，不仅增加库存管理、物流配送的复杂度，还可能导致商家错发货物。

3. 哪些接口可酌情不做幂等处理

有些接口，业务场景简单、数据也相对没那么重要，重复调用概率比较小，且重复调用造成的影响也很小，则可考虑不做幂等处理，以降低开发成本和系统开销。

典型场景如内部OA系统的一些审批

内部审批单（如员工报销审批、部门采购审批）通常具备以下特点，使其无需强制幂等：

调用场景封闭：接口仅在企业内部系统使用，调用者是内部员工或指定系统，不存在外部用户因网络问题重复提交的高频场景。
按钮置灰：且内部系统通常会有前端按钮置灰、提交后跳转等逻辑，从源头减少重复调用。
重复影响极小：即使因异常导致审批单重复提交，后续业务流程可通过 “人工校验” 或 “状态判断” 修正，或者驳回流程（或者删除申请流程）再重新发起~

当然，并不是说这类型接口一定不做幂等处理，这个是结合你实际业务场景评估的，有些场景，幂等可以简单处理的，比如：

一个状态同步的接口，如 “将审批单状态同步到 OA 系统”，即使重复同步，目标系统可通过 “审批单 ID + 当前状态” 判断是否需要更新，重复调用不会产生异常状态。（这种方案就是状态机幂等处理）

4. 通用方案：如何设计幂等接口？

对于重要接口的幂等处理，比如转账接口，跟大家分享一种比较通用的幂等方案哈~~

日常开发中，为了实现交易接口幂等，我是这样实现的：

交易请求过来，我会先根据请求的唯一流水号bizSeq字段，先select一下数据库的流水表

如果数据已经存在，就拦截是重复请求，直接返回成功；
如果数据不存在，就执行insert插入，如果insert成功，则直接返回成功，如果insert产生主键冲突异常，则捕获异常，接着直接返回成功。

流程图如下：

图片

伪代码如下：

/**
 * 幂等处理
 */
Rsp idempotent（Request req）{
  Object requestRecord =selectByBizSeq（bizSeq）;

if(requestRecord !=null){
    //拦截是重复请求
     log.info("重复请求，直接返回成功，流水号：{}",bizSeq);
     return rsp;
  }

  try{
    insert(req);
  }catch(DuplicateKeyException e){
    //拦截是重复请求，直接返回成功
    log.info("主键冲突，是重复请求，直接返回成功，流水号：{}",bizSeq);
    return rsp;
  }

  //正常处理请求
  dealRequest(req);

return rsp;
}

为什么前面已经select查询了，还需要try...catch...捕获重复异常呢？