接口幂等基础题重试安全不是后端玄学一、幂等不是“多点几次也没事”的口号后端基础面试里幂等是高频题。很多回答会说“加唯一键”“用 Redis 锁”。这些都是手段不是定义。幂等的意思是同一个业务请求执行一次和执行多次最终效果一致。接口幂等不是为了好看而是为了处理重试、超时、网络抖动和用户重复点击。没有幂等重试会把一次业务变成多次副作用。二、先定义业务唯一请求幂等设计第一步是找到业务唯一键。支付是订单号消息发送是消息 ID创建任务可以是客户端生成的 request_id。flowchart TD A[客户端请求] -- B[携带幂等键] B -- C{是否处理过} C --|是| D[返回历史结果] C --|否| E[执行业务] E -- F[记录结果] F -- G[返回响应]没有幂等键就很难判断两次请求是不是同一件事。服务端猜不出来。三、用数据库唯一约束兜底Redis 可以加速但数据库唯一约束才是关键兜底。CREATE TABLE idempotency_record ( idempotency_key VARCHAR(128) PRIMARY KEY, status VARCHAR(32) NOT NULL, response_body TEXT, created_at TIMESTAMP NOT NULL );处理请求时先插入幂等记录。插入成功说明第一次处理主键冲突说明已经处理过或处理中。具体状态要区分。四、处理中状态要谨慎返回如果第一次请求正在处理第二次请求来了不能直接说成功。可以返回处理中或者等待一小段时间查询结果。否则客户端会误以为业务已经完成。还要保存响应结果。第一次成功后后续相同幂等键应返回同样语义的结果。不要重新执行一遍业务。最后幂等记录要有过期策略。保存太短重试窗口内会失效保存太久表会膨胀。过期时间要按业务重试周期定。幂等还要处理“成功但响应丢失”的情况。服务端业务已经完成网络断了客户端重试。此时服务端应返回第一次成功的结果而不是再执行一次。保存 response_body 的价值就在这里。处理中状态也要有超时恢复。任务卡住后幂等记录一直是 processing后续请求都会被挡住。可以记录更新时间超过阈值后进入可恢复流程但恢复前要确认业务是否真的未完成。写接口和读接口的幂等要求不同。GET 天然应无副作用POST 创建资源通常需要幂等键PUT 更接近覆盖语义。面试回答时先区分接口语义会比直接说 Redis 锁更靠谱。最后幂等和分布式锁不是一回事。锁控制并发幂等控制重复请求的业务结果。锁释放后重复请求仍然可能再次执行所以最终还得有业务唯一约束兜底。幂等记录要和业务事务尽量放在一起。先写业务表再写幂等表中间失败会留下灰色状态先写幂等表再执行业务也要处理业务失败后的状态回滚。面试时能讲出事务边界会比只说“加 Redis”扎实很多。消息消费也需要幂等。队列通常是至少一次投递同一消息可能被处理多次。消费者可以用 message_id 做幂等键业务表用唯一约束兜底。重复消息来时返回已处理即可。最后幂等不是万能补丁。请求本身如果没有稳定业务键后端很难判断重复。客户端、网关和服务端要一起约定幂等键单靠某一层猜不出来。测试幂等时不要只测连续两次成功请求。还要测第一次超时、第一次业务成功但响应失败、第一次处理中服务重启、第二次并发到达。幂等问题最容易出现在这些尴尬中间态。五、总结接口幂等的核心是定义业务唯一请求并保证重复请求不会产生重复副作用。幂等键、状态记录、数据库唯一约束和历史结果返回是基础。重试安全不是玄学是后端系统必须写清楚的一条合同。