分布式高并发系统接口幂等性设计与实践

一、幂等性：分布式系统的必修课

1.1 什么是接口幂等性

接口幂等性指的是：用户针对同一操作发起一次或多次请求，最终产生的业务效果是一致的，不会因为请求被执行多次而引入额外的副作用。

这一概念源自数学：若函数满足 f(f(x)) = f(x)，则称其为幂等函数。映射到软件工程中，含义是“同一个操作执行一次和执行 N 次，对系统状态的影响相同”。

需要特别强调两点：

• 幂等关注的是“结果与副作用”，而不是“响应完全相同”。两次请求的响应报文可以不同（例如第二次返回“重复请求”提示），但只要系统内的数据状态没有被二次改变，就可以认为满足了幂等。
• 幂等是“设计与兜底”出来的，而不是“碰巧”实现的。默认情况下，绝大多数写接口并不幂等。

1.2 高并发场景下，重复请求几乎不可避免

很多开发者最初容易把重复请求归咎于“用户手抖”，但在分布式系统中，重复请求更多是基础设施的固有行为：

（1）用户侧重复触发
表单提交按钮被快速点击两次、页面刷新后重新提交、浏览器前进后退导致的重复请求等。这是最直观的场景：保存按钮连点两次，数据库里出现两条仅主键不同的重复记录。

（2）超时重试机制
为了应对网络抖动和服务超时，调用方（客户端、网关、远程调用框架）通常会配置重试策略。关键问题在于：一次超时并不代表对方没有处理成功——请求可能已经落库，只是响应没有及时返回。此时如果直接返回失败，调用方会误判业务状态；如果发起重试，服务端就可能重复执行。这就是“重试必然放大重复请求”的根源。

（3）消息队列的重复消费
主流消息队列一般提供“至少一次”（at-least-once）的投递语义以保证可靠性：生产者发送后未收到确认会重发，消费者处理完成但确认丢失会重新投递，消费者组再均衡时也可能重复拉取。因此“同一条消息被消费多次”是常态而非异常，消费逻辑必须自带幂等能力。

（4）任务调度与故障转移
定时任务的重复触发、服务实例宕机后任务被重新分配等，都会导致同一段业务逻辑被重复执行。

结论：在高并发分布式系统中，“重复”是常态，幂等性不是可选项，而是对外接口的基本设计要求。

二、哪些操作需要重点设计幂等性

不同类型的数据库操作，天然幂等性差异很大：

1. 查询操作：只读不写，天然幂等，一般无需额外处理。
2. 插入操作：最容易出问题。同样的请求执行两次，通常会产生两条记录，必须重点防护。
3. 更新操作：需要区分两种情况。
   • 覆盖式更新（绝对值赋值），例如 update user set status = 1 where id = 1，执行多少次结果都一样，天然幂等；
   • 计算式更新（增量变更），例如 update user set status = status + 1 where id = 1、扣减库存、余额转账等，每执行一次结果都会变化，重复执行必然导致数据错误，必须设计幂等。
4. 删除操作：按条件删除属于天然幂等（第二次删除影响行数为 0），但要留意接口返回值与后续级联逻辑（如删除后赠送积分）是否被重复触发。

三、主流幂等性方案详解

3.1 数据库唯一索引：最可靠的兜底防线

原理：为业务唯一键建立唯一约束，重复插入时数据库直接抛出冲突异常，应用层捕获后按“已处理”处理。

CREATE TABLE order_info (
  id          BIGINT PRIMARY KEY,
  order_no    VARCHAR(64) NOT NULL COMMENT '业务订单号',
  amount      DECIMAL(10,2),
  create_time DATETIME,
  UNIQUE KEY uk_order_no (order_no)
);

try {
    orderService.createOrder(request);
} catch (DuplicateKeyException e) {
    // 命中唯一索引，说明是重复请求
    return orderService.queryByOrderNo(request.getOrderNo());
}

要点：

• 唯一键必须是“业务维度”的唯一标识（订单号、流水号、外部请求号），而不是自增主键；
• 捕获冲突后，建议返回首次请求的处理结果，而不是报错，让调用方无感知；
• 它是“最后一道防线”：即便上游拦截全部失效，也能保证数据不脏。

局限：仅适用于插入类操作；高并发下冲突请求会持续打到数据库，通常需要配合上游拦截手段。

3.2 防重令牌机制：先领票，再办事

原理：请求进入业务前，先到服务端领取一个全局唯一令牌，服务端将令牌写入缓存并设置过期时间；业务提交时携带令牌，服务端原子地“校验存在并删除”，删除成功才执行业务，否则判定为重复请求。

// 1. 页面加载 / 预下单阶段，签发令牌
String token = UUID.randomUUID().toString();
cache.setex("idem:token:" + token, "1", 600); // 10分钟有效
// 2. 提交时校验：判断存在 + 删除必须原子完成
if (cache.delete("idem:token:" + token)) {
    return orderService.createOrder(request); // 首次请求
} else {
    return Response.duplicate(); // 重复请求
}

要点：

• “判断存在”和“删除”两步必须原子完成，否则并发请求可能同时通过检查（典型的 check-then-act 竞态问题）；
• 令牌应与业务维度绑定，避免跨单复用；
• 该方案能将绝大多数重复请求拦截在数据库之前，适合表单提交、下单等写场景。

3.3 分布式锁：串行化关键路径

原理：以业务唯一键构造锁键，同一业务键的并发请求只有一个能获取锁，获取失败的请求要么快速失败，要么短暂等待后查询处理结果。

String lockKey = "lock:order:" + request.getOrderNo();
if (!lockClient.tryLock(lockKey, 10, TimeUnit.SECONDS)) {
    return Response.processing(); // 处理中，请勿重复提交
}
try {
    if (orderService.exists(request.getOrderNo())) {
        return orderService.getByOrderNo(request.getOrderNo()); // 幂等返回
    }
    return orderService.createOrder(request);
} finally {
    lockClient.unlock(lockKey);
}

要点：

• 锁本身只解决“并发互斥”，必须配合“锁内先查再写”才能实现幂等；
• 注意锁超时与业务耗时的匹配，以及持有者标识与安全释放（避免误删他人的锁）；
• 锁粒度要足够细（按订单号而非按用户），否则会误伤正常并发。

3.4 乐观锁：为更新类操作而生

原理：给数据行引入版本号，更新时携带“我基于哪个版本修改”的条件，只有版本匹配才更新成功，否则视为冲突或重复操作。

-- 扣减余额：条件更新，天然防重复执行
UPDATE account
SET balance = balance - 100, version = version + 1
WHERE id = 1 AND version = 5;

若影响行数为 0，说明当前数据已被其他请求修改（或本次为重复请求），业务可返回失败或重读最新状态重试。

要点：

• 无需引入额外中间件，适合库存扣减、状态变更等更新场景；
• 高并发冲突激烈时重试率升高，可结合“条件更新 + 短重试”策略；
• 与计算式更新配合，可以把“不幂等的增量操作”改造成“带条件的幂等操作”。

3.5 状态机：用状态流转约束重复执行

原理：将业务对象的生命周期建模为有限状态集合，状态只能沿预定义方向单向流转，更新时带上“前置状态”条件。

UPDATE order_info
SET status = 'PAID', pay_time = now()
WHERE order_no = '20240601001' AND status = 'UNPAID';

重复的支付回调再次执行时，订单状态已不是 UNPAID，影响行数为 0，业务直接返回成功即可。该方案广泛适用于订单、支付、审批流等流程型业务，且与消息重复消费场景天然契合。

3.6 去重表（流水表）：借助数据库事务的原子性

原理：新建一张去重表，以“业务类型 + 业务唯一键”作为唯一索引；业务操作与插入去重记录放在同一个本地事务中提交。重复请求到来时，插入去重记录必然违反唯一约束，事务回滚，业务不执行。

BEGIN;
INSERT INTO dedup_record (biz_type, biz_no, created_at)
VALUES ('PAY_NOTIFY', '20240601001', now()); -- 唯一索引保护
UPDATE order_info SET status = 'PAID' WHERE order_no = '20240601001';
COMMIT;

要点：

• 依赖数据库事务保证“记录请求”与“执行业务”的原子性，可靠性最高；
• 适合消息消费、支付回调等对一致性要求高的场景；
• 注意去重表的清理与归档策略，避免数据无限膨胀。

3.7 请求唯一标识 + 缓存去重：轻量高效的前置拦截

原理：调用方为每次业务操作生成全局唯一请求标识（业界常通过统一的幂等键请求头传递），服务端以该标识为键执行“不存在才写入”的原子操作，写入成功即首次请求，失败即重复请求。

String requestId = header.get("X-Request-Id"); // 调用方生成的全局唯一ID
if (!cache.setIfAbsent("idem:req:" + requestId, "1", 24, TimeUnit.HOURS)) {
    return Response.duplicate();
}
return doBusiness(request);

要点：

• 性能好、成本低，适合高并发写入的前置拦截；
• 通常作为“第一道闸门”，与数据库唯一索引配合形成双层防护；
• 过期时间要覆盖业务可能的最大重试窗口。

3.8 前端与网关的辅助手段

按钮点击后置灰、防抖节流、表单一次性提交标识、网关层对相同请求指纹的短窗口去重等，都能显著减少重复请求的到达量。但必须明确：这些只是“减量”手段，网络重试与消息重复无法在前端消除，服务端幂等仍是必需的兜底能力。

四、方案对比与选型建议

方案	适用操作	可靠性	性能成本	典型场景
唯一索引	插入	高（兜底级）	低	下单、注册
防重令牌	插入/提交	中高	中	表单、下单页
分布式锁	通用	中高	中	关键写路径
乐观锁	更新	高	低	库存、余额
状态机	状态流转	高	低	订单、支付
去重表	通用	高	中	消息消费、回调
缓存去重	通用	中（需兜底）	极低	高频写前置拦截

选型经验：

1. 插入类：缓存去重或防重令牌做前置拦截 + 唯一索引做最终兜底，形成双保险；
2. 更新计算类：乐观锁或状态机，把增量操作改造成条件操作；
3. 消息消费与回调：去重表（强一致）或缓存去重 + 唯一索引（高性能）；
4. 不要迷信单一方案，幂等设计应分层：前端减量 → 网关/缓存拦截 → 业务逻辑防重 → 数据库约束兜底。

五、容易被忽视的工程细节

1. 幂等键的选择：应选取能唯一标识“一次业务意图”的键（订单号、外部流水号、幂等键请求头），而不是用户 ID、IP 等粗粒度标识，否则会误杀正常请求。
2. 重复请求的返回语义：对已成功处理的重复请求，应返回与首次一致的成功结果，而不是抛出“重复提交”错误，避免调用方进入不必要的补偿或告警流程。
3. 原子性是生命线：任何“先查后写”的逻辑都必须原子化（数据库约束、原子命令、锁或事务），否则在并发下形同虚设。
4. 缓存方案要考虑失效与降级：设置合理 TTL；缓存不可用时的降级路径必须落到数据库约束上。
5. 监控与对账：统计重复请求命中率、唯一索引冲突量，建立对账机制，及时发现异常重复流量。

六、总结

幂等性的本质，是为“不可靠的重复执行”提供确定性的结果保障。在分布式高并发系统中，重复请求由网络重试、消息重复投递、故障转移等机制天然引入，无法根除，只能防御。实践中的成熟做法是构建多层级防御体系：以缓存去重或防重令牌拦截绝大多数重复流量，以乐观锁、状态机约束更新类操作，以唯一索引和去重表作为数据一致性的最终防线，同时以监控与对账持续验证防护有效性。理解每种方案的原理与边界，并结合业务场景合理组合，才能真正构建出让调用方放心重试的可靠接口。