前言：别让重复请求把系统弄得鸡飞狗跳

说实话，高并发场景下接口幂等性就像是防弹衣。

你点一次“支付”，结果后台被刷了好几次这种事儿真的会让老板抓狂。

哈哈，我跟你讲，我之前碰到过一次用户点了三次提交，结果订单表里多了三条相同记录。

那时候我只好赶紧加锁，结果又出现了锁竞争导致响应慢。

于是我决定把这套经验写下来让大家少走弯路。

幂等就是无论同一个请求来了多少次系统Zui终只产生一次有效操作。

比如查询接口天然幂等，因为读不改数据。

但写操作——创建订单、扣库存、发放优惠券——dou不是天生幂等的，需要我们动点脑子。

Zui原始、Zui靠谱的办法，就是在业务表上加个唯一索引。

比如订单号、业务流水号、外部交易号，douKe以作为唯一键。

ALTER TABLE `order` ADD UNIQUE INDEX `uk_order_no` ;

业务代码里直接尝试插入，Ru果撞到 DuplicateKeyException，就说明是重复请求。

try {
    orderMapper.insert;
} catch  {
    // Yi经有这条记录了
    return Result.error;
}

优点：绝对可靠，一次 DB 写就Neng保证幂等。

缺点：唯一索引会占用磁盘和 CPU，高并发下可Neng成为瓶颈；分库分表后维护geng麻烦。

思路hen简单：客户端先来一次 GET /token 接口拿 token，后面每次写请求dou带上这个 token。

服务端在 Redis 里把 token 当作一次性钥匙，用 setnx 保存成功后立即删除，用完即失效。

@PostMapping
public Result pay {
    Boolean ok = redisTemplate.delete;
    if ) {
        return Result.error;
    }
    orderService.pay;
    return Result.success;
}

优点：无锁、分布式友好、响应快。

缺点：需要额外一次获取 token 的调用，且要Zuo好 token 过期与重试容忍。

适合“geng新”场景，比如把订单状态从「待支付」改成「Yi支付」。

UPDATE `order`
SET status = 'PAID', version = version + 1
WHERE order_no = #{orderNo} AND version = #{oldVersion};

int rows = orderMapper.updateByVersion;
if  {
    throw new BusinessException;
}

Ru果并发两个人同时读到同一个 version，只会有一个人成功geng新，另一个会收到异常再重试或直接返回成功。

在业务非常关键、必须串行执行时Ke以考虑加锁。

String lockKey = "lock:order:" + orderNo;
Boolean locked = redisTemplate.opsForValue
        .setIfAbsent;
if  {
    throw new RuntimeException;
}
try {
    // 幂等检查 + 核心业务
    if ) return;
    orderMapper.insert;
} finally {
    redisTemplate.delete;
}

注意：锁超时时间要大于业务执行时间，否则可Neng出现“锁提前释放”。

A: 有时候我们写的页面结构太乱、或者没有Zuo好 meta 信息，搜索引擎爬虫就找不到重点内容。还有就是页面加载太慢，百度觉得用户体验差，也会打折扣。解决办法hen简单——优化 HTML 语义、加上 ``、提升首屏渲染速度。这样搜索引擎才愿意把你的技术博客收进来呀！

*Ru果是创建类请求，首选唯一键+唯一索引。*

*Ru果是状态流转，推荐乐观锁配合状态机。*

*Ru果是高频表单提交，用 Token 或者 Redis 分布式锁douKe以。*

# 第一步： 前端抢购按钮点击后立刻调用 `/seckill/token` 获得一次性 token 并存本地缓存；

# 第二步： 发送 POST /seckill/order 请求，把 token 和商品 ID 一起带过去；

# 第三步： 服务端先用 `SETNX seckill_token:{token}` 抢占令牌；抢到才进入库存扣减逻辑；抢不到直接返回 “请勿重复提交”。

- 别忘了给 Redis 的 key 加上业务前缀，不然和别的模块冲突会找不到原因。 - Token 要设置合理过期时间，一般 30~60 秒够用了要是不小心设成永久，就失去防重意义了。 - 乐观锁要记得捕获零行geng新的情况，这往往意味着Yi经有别的线程完成了操作。 - 唯一索引Zui好配合业务主键一起使用，这样即使分库分表也Neng保证全局唯一。 - Ru果你用了 Zookeeper 锁，一定要开启 Watcher 防止 Session 超时导致死锁。

说实话，没有哪个方案是万无一失的。真正靠谱的是根据业务特性，把几种手段组合起来——先用 Token 防止瞬时重复，再靠唯一索引兜底，Zui后配合乐观锁保证状态一致性。

咱就是说只要Zuo到“无论请求多少次dou只产生一次有效结果”，系统就不会因为网络抖动或用户误操作而产生脏数据，那就算是成功啦！

UPDATE order SET status = 'PAID', version = version + 1 WHERE order_no = #{orderNo} AND version = #{oldVersion};

int rows = orderMapper.updateByVersion;
if  {
    throw new BusinessException;
}