接口幂等性方案详解

接口幂等性方案详解Hi我是阿昌。今天记录一下接口幂等性。一、什么是幂等幂等是数学概念比如f(n) 1ⁿ不管 n 取多少结果永远是 1。搬到软件开发里不论执行多少次相同的请求产生的效果和返回的结果都和发出单个请求是一样的。对应到数据库操作INSERT不插入重复数据UPDATE多次相同更新后数据依然正确二、为什么需要幂等接口幂等问题通常来自这些场景网络波动导致客户端重试用户手抖重复点击消息队列重复消费接口响应慢前端超时自动重试RPC 框架的重试机制不保证幂等会怎样举个最直接的例子——支付。用户在付款时连点了两下后端处理了两次扣款账户被扣了两次钱。这种 Bug 在涉及钱的业务里就是事故级别。另外幂等不是前端把按钮置灰就完事了后端也必须做。前端的限制容易被绕过了。三、常见方案概览后端保证幂等的方式大致有几类方案原理适用场景悲观锁加锁让同一时刻只有一个请求执行写多读少乐观锁版本号/CAS冲突时重试或失败读多写少唯一索引数据库层面保证数据唯一INSERT 场景去重表用一张表记录已处理的请求 ID通用场景分布式锁跨进程加锁分布式环境Token 机制先取 token请求时校验并删除表单提交四、悲观锁Java 本地锁ReentrantLock、synchronized这类 JDK 自带的锁只能保证同一个 JVM 进程内的线程安全。privatefinalReentrantLocklocknewReentrantLock();publicvoidprocess(StringorderId){lock.lock();try{// 业务逻辑}finally{lock.unlock();}}问题很明显分布式环境下多个服务实例各自有各自的锁互不影响。所以本地锁只在单机场景有用。数据库排他锁MySQL 的SELECT ... FOR UPDATE可以在事务中对记录加排他锁X 锁阻止其他事务同时修改。STARTTRANSACTION;SELECT*FROMt_orderWHEREid1FORUPDATE;-- 业务判断 更新UPDATEt_orderSETstatusPAIDWHEREid1;COMMIT;几个注意点必须在事务中使用且存储引擎要支持InnoDB查询条件必须走索引否则会锁全表高并发下锁竞争激烈线程阻塞会导致大量上下文切换存在死锁风险五、乐观锁乐观锁通常用版本号机制或 CAS 实现。核心思路是更新时检查版本号一致才更新不一致说明被别人改过了。-- 初始 version 1UPDATEgoodsSETpriceprice100,versionversion1WHEREid1ANDversion1;-- 这条执行时 version 已经变成 2条件不满足更新失败UPDATEgoodsSETpriceprice100,versionversion1WHEREid1ANDversion1;相比悲观锁不会阻塞线程没有死锁问题写冲突少时性能更好但只适用于 UPDATE 场景如果冲突频繁会变成失败→重试→失败的循环CPU 反而飙升悲观锁的开销是固定的阻塞乐观锁的开销随冲突频率增长。写多的时候反而悲观锁更合适。六、唯一索引 / 去重表唯一索引在需要保证唯一的字段上加唯一索引重复插入直接抛异常。CREATETABLEt_order(idINTUNSIGNEDPRIMARYKEYAUTO_INCREMENTCOMMENT主键,codeVARCHAR(200)NOTNULLCOMMENT流水号,customer_idINTUNSIGNEDCOMMENT会员id,amountDECIMAL(10,2)UNSIGNEDNOTNULLCOMMENT总金额,UNIQUEunq_code(code))COMMENT订单表;重复插入时 MySQL 抛出Duplicate entry代码里 catch 一下就好。但建议的做法是不要把唯一索引当作唯一的幂等手段而是作为兜底。就像开篇那个阿里面试的例子Redisson 分布式锁在前面拦截大部分重复请求唯一索引兜底防止锁失效时产生脏数据。去重表去重表是唯一索引的变体——单独建一张表记录已处理的请求 ID。CREATETABLEdeduplication(idINTUNSIGNEDPRIMARYKEYAUTO_INCREMENT,processed_codeVARCHAR(200)NOTNULLCOMMENT已处理的流水号,UNIQUEunq_processed_code(processed_code))COMMENT去重表;流程请求进来 → INSERT INTO deduplication (processed_code) VALUES (XXX) ├── 插入成功 → 第一次请求 → 执行业务逻辑 └── 插入失败唯一键冲突→ 重复请求 → 直接返回本质和唯一索引一样只是把幂等判断单独抽了一张表不跟业务表耦合。七、分布式锁分布式系统下不同服务实例跑在不同的 JVM 里本地锁管不到。这时候需要分布式锁。通常基于Redis或ZooKeeper实现Redis 用得更多。比如 Redisson 的RLockRLocklockredissonClient.getLock(order:lock:orderId);try{if(lock.tryLock(5,10,TimeUnit.SECONDS)){// 获取锁成功执行业务}}finally{lock.unlock();}基于 MySQL 也能做分布式锁但一般不推荐——性能差没有锁失效机制容易死锁。分布式锁的核心作用和悲观锁一样同一时刻只让一个请求执行业务逻辑。区别是它能跨进程。配合幂等判断的逻辑通常是加锁 → 查订单状态 → 已处理直接返回 : 继续处理 → 释放锁八、Token 机制Token 机制需要两次请求第一步客户端 GET /token → 服务端生成 token 存入 Redis返回给客户端 第二步客户端 POST /submit携带 token → 服务端校验并删除 token关键点Token 必须由服务端生成可以签名防篡改Token 设置短有效期验证方式一般是删除 token删除成功才算有效得物技术有一张流程图把这个过程画得很清晰客户端 服务端 | | |── GET /token ──────────| |── token ────────────── | | | |── POST /submit token | | |── 删除 tokenredis del | | ├── 删除成功 → 执行业务 | | └── 删除失败 → 拒绝请求 |── result ──────────── |先删 token 还是先执行业务两者都有风险先执行业务token 还在客户端可能重试导致第二次也通过先删 token业务执行超时重试时 token 已经没了请求失败一般建议先删 token。如果业务执行失败客户端重新获取 token 再请求。只有极少数请求会碰到这个问题属于可接受范围。九、方案对比方案优点缺点适用悲观锁实现简单保证强一致性能差可能死锁写多单机乐观锁无阻塞无死锁冲突多时 CPU 高仅 UPDATE读多写少更新唯一索引数据库兜底绝对可靠仅 INSERT插入兜底去重表不耦合业务表多一张表多一次插入通用分布式锁跨进程灵活引入中间件有网络开销分布式环境Token不需要锁两次请求实现复杂表单提交重复点击十、实际怎么选没有万能方案通常都是组合使用。开篇那个面试例子就是个很好的实践Redisson 分布式锁主力拦截 MySQL 唯一索引兜底防脏数据一个典型的订单幂等处理流程请求进来 │ ├── 1. 参数校验 │ ├── 2. 加分布式锁key 订单号 │ └── 获取失败 → 返回处理中 │ ├── 3. 查订单状态 │ └── 已处理 → 返回结果释放锁 │ ├── 4. 执行业务逻辑 │ ├── 5. INSERT 订单记录唯一索引兜底 │ └── Duplicate entry → 回滚 │ └── 6. 释放锁返回结果核心原则就一条永远不要让唯一索引单兵作战也永远不要只靠分布式锁。两者组合各司其职。总结接口幂等不是什么高大上的概念但它属于那种不出事没人管出了事就是大问题的基础能力。几个要点再强调一下前后端都要做不能只靠前端置灰按钮涉及钱的业务必须做没有商量余地没有银弹方案根据场景组合使用唯一索引作为兜底是好习惯别省Token 方案先删 token 再执行业务重试时重新获取即可