如何设计一个幂等接口，新人只会说‘加Token’，老炮这样答直接过……#后端 #后端面试 #java面试 #程序员 #计算机

你们的转账接口被用户重复点击了，钱被扣了两次，怎么解？我给接口加个token，提交后把token置为已用。token存在哪儿？Redis？还是数据库？万一服务重启，token丢了怎么办？你总不能要求每家都带着同一个token吧？你又答不出来了。 这道题是美团三面的高频题，去年就刷掉百分之七十的候选人。为什么这么难？因为它考的是你对分布式一致性的理解深度。点赞、收藏这篇，下次面试别再卡在这道题上。 我给你还原两个真实面试场景，看看你能达到哪个水平。怎么设计幂等接口？加个唯一请求ID，提交时验证，验证通过就处理。唯一ID存哪？存Redis。Redis挂了怎么办？那就先不处理？用户转一百万，Redis挂了你们就不处理了？ 怎么设计幂等接口，分两个维度。第一是插入场景，用业务唯一键防重，比如订单号加用户ID加时间戳。第二是更新场景，用乐观锁和悲观锁。插入场景我详细说说：前端生成一个唯一token，这个token不是接口级别的，而是业务级别的，跟业务数据绑定存在数据库。接口进来先查这个token状态，是处理中就返回重复提交，是成功就返回已处理，只有未处理才执行业务，执行完后状态变更为成功，这是原子操作，要么全成功，要么全失败。 不错。那你用什么保证原子性？用数据库唯一索引，比如转账表有唯一约束：用户ID加业务ID加token，只有第一个请求能插入成功，后续请求会报duplicate exception，我捕获这个异常就知道是重复请求。那分布式环境下呢？两台机器同时拿到token，状态是未处理，怎么保证只有一个执行？用分布式锁，但分布式锁本身也要考虑原子性，所以最优方案是直接依赖数据库唯一约束，而不是先查后写。 看到差距了吗？一年经验只会说加token，老炮从业务场景说到技术选型，从单点说到分布式，从Redis说到数据库唯一索引，层层递进。想知道老炮怎么做到的吗？我来逐步给你拆解：幂等性不是加个字段那么简单，它涉及到并发控制、分布式、一致性、数据库原理等多个知识点。说白了，幂等性就是做一次和做一百次效果一样。 三种场景，每种场景一个解法。场景一：插入防重，比如创建订单、注册用户。这种场景的解法是业务标识加数据库唯一索引。用户下单时带上订单号，这个订单号在数据库有唯一索引约束，只有第一个请求能插入成功，后续请求会触发唯一键冲突，数据库直接拒绝。这就是让数据库替你做并发控制，比你在代码里写if判断靠谱一万倍。 场景二：更新防重复，比如扣款、扣库存。这种场景的解法是乐观锁。你在SQL里加个版本号条件：update count set balance = balance - 100 where ID = 1 and version = 1，只有版本号匹配时才能更新成功，更新后版本号加一。第二个请求来的时候，版本号已经变成2了，where条件不满足，更新失败，你捕获这个更新失败的返回值，就知道是重复操作。 场景三：异步回调防重，比如第三方支付回调。这种场景的解法是状态机加唯一键。第三方回调会带一个唯一的transaction ID，你在数据库建一张回调记录表，用transaction ID做唯一索引。回调来的时候先插入，插入成功才处理，插入失败说明已经处理过了，幂等就解决了。但还有个问题：第一个请求处理到一半，第三方又回调了一次怎么办？这就需要状态机控制，只有状态是待处理才能处理，处理中加锁，防止并发重复处理。 换个说法就是，幂等性不是一道填空题，是一道场景设计题。你得先问清楚业务场景：插入还是更新？同步还是异步？并发量多大？然后再给方案，脱离场景谈方案都是耍流氓。这题考的不是你知不知道幂等，是考你能不能根据不同场景给出不同方案。只会加token是初中级水平，能针对插入、更新、异步三种场景给出完整方案的才是高级水平。下次面试前想一想，你们系统的核心接口有没有做幂等？做了的话是怎么做的？抖音。