四种幂等方案的对比分析与选型思路

所有分布式系统接口都必须幂等，但没有任何一种幂等方案能适配全部业务场景，选型的核心依据是数据一致性要求与并发量级的组合。实践中最常用的是唯一键约束、状态机校验、分布式锁和Token机制这四种方案，各自在复杂度、性能和安全性上差异明显，工程落地需要按具体场景做取舍。

幂等的本质是重复请求与一次执行的抽象

幂等的定义是：同一个操作无论执行多少次，其结果与执行一次完全一致。在HTTP语义中，GET、PUT、DELETE天然幂等，但POST不幂等，实际的业务接口必须自行设计幂等逻辑。

判断一个系统是否实现幂等，核心考察三个层面：接口层面是否拦截重复提交，数据层面是否保证结果收敛一致，业务层面是否避免重复扣减库存或重复发放奖励。缺少任何一层的保护，高并发下的重复请求都可能穿透到核心数据库产生脏数据。

从数学抽象来看，幂等操作要求服务端状态转移函数 f 满足 f(f(x)) = f(x)。这意味着第一次请求执行完整的业务逻辑，后续相同请求需要直接返回第一次的执行结果或直接忽略。

唯一键约束方案用数据库索引换取确定性

唯一键约束方案是成本最低、效果最确定的幂等实现方式，它直接利用数据库的唯一索引在存储层杜绝重复数据写入。核心做法是在业务表中添加一个业务唯一标识字段，并为其创建唯一索引，重复插入时数据库抛出冲突异常，应用捕获后返回成功或查询已有结果。

这种方案的适用前提是操作的本质为插入型数据，比如创建订单、生成支付流水、提交表单记录。对于更新型场景，唯一键方案无法独立生效，需要结合其他机制。性能损耗来自唯一索引的维护成本，在写入密集型场景中会放大磁盘IO。

以订单创建为例，接入支付回调时用外部商户单号作为唯一键，具体实现如下。

CREATE TABLE pay_order (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  merchant_trade_no VARCHAR(64) NOT NULL,
  order_status TINYINT DEFAULT 0,
  UNIQUE KEY uk_trade_no (merchant_trade_no)
);

INSERT INTO pay_order (merchant_trade_no, order_status)
VALUES ('M20240001', 0)
ON DUPLICATE KEY UPDATE order_status = order_status;

SQL语句中的ON DUPLICATE KEY UPDATE语法保证了重复插入不会报错而是忽略更新，实际应用需要根据数据库类型选择对应的原子操作，PostgreSQL使用ON CONFLICT DO NOTHING，MySQL的此方案在单条SQL内保证原子性，不需要额外事务包裹。

状态机校验方案利用字段流转拦截非法请求

状态机校验方案适用于业务对象存在明确状态流转路径的场景，比如订单从待支付到已支付、再到已发货，每个状态机节点只允许固定的合法迁移。实现方式是在更新语句的条件中携带当前期望状态，若实际状态不匹配则更新影响行数为零，以此判断请求重复或无效。

核心SQL通过将状态条件写入WHERE子句实现原子化条件更新，避免了先查询后更新的竞态窗口。这种方案与唯一键方案相比，不需要创建额外索引，也天然适用于更新型操作。

以支付回调更新订单状态为例，限定订单必须先处于待支付状态才能变更为已支付状态。

UPDATE trade_order
SET order_status = 'PAID', paid_time = NOW()
WHERE order_no = 'A20241001001'
  AND order_status = 'PENDING_PAYMENT';

执行后检查受影响行数，若为0则代表订单状态已经流转，本次请求应当直接返回成功。这种基于行数判断的机制完全依赖数据库的行锁与原子更新，在高并发下不会产生覆盖更新，但前提是业务状态流转路径必须严格单一，不允许跳变，否则会漏掉部分非法流转。

复合状态机可以覆盖更复杂的场景，比如同时校验多个条件字段的当前值，或者在更新时同时累加版本号字段。该方法与乐观锁方案在原理上一致，差别仅在于乐观锁使用独立的版本号字段而状态机使用业务状态字段。

分布式锁方案将并发互斥转化为串行执行

分布式锁方案通过外部锁服务将同一业务键的并发请求转化为串行执行，从而保证任意时刻只有一个请求能操作共享资源，适合对库存扣减、账户余额变更等资源型操作做幂等保护。实现要点是锁的粒度必须与业务幂等键对齐，比如使用用户ID或订单号作为锁的key，锁超时时间需要大于业务最慢执行时间。

Redisson为客户提供的分布式锁实现了看门狗自动续期机制，但工程上需要警惕锁失效后的并发穿透。锁并非解决幂等的银弹，它只能降低并发冲突概率，无法直接从数据层面保证重复请求的结果一致，事务提交后若在通知阶段失败，锁已释放而业务结果未返回到调用方，此时重试仍会再次获得锁并重复执行业务逻辑。

因此分布式锁通常需要与唯一键方案联合使用：锁解决并发互斥，唯一键解决数据唯一性兜底。以Go语言使用Redis构建的简单分布式锁为例，核心逻辑如下。

import (
    "github.com/redis/go-redis/v9"
    "time"
)

func TryLock(ctx context.Context, rdb *redis.Client, key string, ttl time.Duration) (bool, error) {
    ok, err := rdb.SetNX(ctx, key, "locked", ttl).Result()
    if err != nil {
        return false, err
    }
    return ok, nil
}

func Unlock(ctx context.Context, rdb *redis.Client, key string) error {
    // 使用Lua脚本保证原子性：先比较令牌再删除
    script := redis.NewScript(`
        if redis.call("get", KEYS[1]) == ARGV[1] then
            return redis.call("del", KEYS[1])
        end
        return 0
    `)
    return script.Run(ctx, rdb, []string{key}, "unique-token").Err()
}

解锁时传入唯一令牌可以避免误删其他请求持有的锁。生产环境中分布式锁的重要权衡在于引入额外的中间件依赖，同时锁服务本身的可用性直接决定接口的可用性，需要为锁服务部署高可用集群。

Token机制前置校验降低无效请求计算开销

Token机制通过预先发放一次性令牌并在请求时校验删除令牌，使重复请求在进入核心业务逻辑前就被拦截，适用于表单提交、支付按钮防重等前端驱动的场景。完整的执行流程分为两个阶段：客户端先调用获取令牌接口，服务端生成全局唯一token并存储；执行业务时客户端携带token，服务端先校验并删除token，删除成功才继续执行后续逻辑，删除失败直接返回重复请求。

Token的存储可以使用Redis的SETNX命令并在抓取时实现原子删除。由于先删除令牌再执行业务，若删除后业务执行失败，本次操作的token已消耗，客户端需要重新获取令牌才能发起重试，这会让用户感觉请求失败后需要重新填写表单。改进做法是为token增加有效期，并在token中关联业务参数哈希，校验时同时比对参数是否一致。

Token机制的时间窗竞态问题需要特别注意：Redis的删除操作与业务执行之间并非严格原子，理论上极端场景下两次并发携带同一token的请求可能在删除操作之前同时通过校验，因此它无法达到强一致性，只能提供最终一致性的防重效果。

不同场景下的方案组合决策

没有万能方案，但有清晰的选型路径。据国际数据公司IDC《分布式应用稳定性实践白皮书》数据显示，约有67%的分布式系统线上故障与接口重复请求导致的并发覆盖写入有关，幂等方案无法完全消除此类故障，但合理的方案组合能将其概率降低一个数量级。因此架构师需要在设计阶段就确立幂等基线，而非事后靠运维脚本修补数据。

判定条件分为三个优先级：首先判断操作是插入型还是更新型，插入型优先选择唯一键约束；其次判断是否存在上游回调重试，存在则叠加状态机校验防止重复回调；最后判断是否存在高并发抢购或人为连点，存在则在前端接入Token机制或分布式锁做拦截。

以一个典型电商下单支付全链路为例，完整的幂等设计应当包含四层防护：前端提交订单携带Token并在Redis中预存、订单表设置商户订单号唯一索引、订单状态字段用状态机流转、支付回调处理使用分布式锁锁定用户维度防并发。这样的组合设计使每一层都有明确的幂等职责，且层与层之间不会互相依赖，即使某一层失效，下游仍有兜底保护。

幂等方案实施中的常见落地坑点

方案选型再完善，落在工程实现上仍有一些高频坑点需要回避。首先是唯一键冲突的异常捕获不完整，很多团队只捕获了DuplicateKeyException却没有捕获底层数据库驱动抛出的SQLIntegrityConstraintViolationException，导致重复请求直接以500错误返回给调用方。

第二个高频问题发生在分布式锁的续期逻辑上，业务执行超过锁超时时间而未完成，看门狗自动续期失效后锁被提前释放，后续重试请求趁虚而入。该问题的标准解法是取消看门狗延期并将锁超时设置为业务最大耗时与安全冗余的加和，同时引入唯一键兜底。

第三个坑是Token机制中的参数一致性校验被省略，若直接使用Token本身作为幂等键而不校验请求参数的哈希值，攻击者可以通过复用同一个合法Token提交修改后的参数使服务端执行不同的业务逻辑，这已经构成严重的越权漏洞。因此Token必须关联业务上下文标识，比如对用户ID、订单金额、商品编号做摘要签名，校验Token时同时比对签名信息。

最后一个隐蔽的问题出现在状态机方案与缓存的一致性上，不少团队将订单状态写入Redis缓存后直接修改数据库，顺序反了导致并发时候读到旧状态。正确的顺序永远是先操作数据库事务提交成功，再更新缓存。

幂等方案的设计本质上是一项防御性工程实践，四种方案虽然有明确的适用边界，但在高可靠系统中应视作组合拳而非单选题。对应设计结论是：数据表建立唯一索引兜底，状态流转用数据库条件更新锁并发，对外接口提供Token防重复，核心资源操作通过分布式锁降低冲突量，四个维度各司其职才能构建可靠的幂等防线。