1. 从一场重复扣款事故说起幂等性到底是什么1.1 事故现场还原重复请求是从哪三条路进来的先讲一件我亲身复盘过的线上事故。某次大促晚上我们接到客服反馈说不少用户在支付成功后看到扣了两笔钱。查了日志发现同一笔订单在业务系统里被成功处理了两次第一次是用户手速快提交下单请求后看到页面没跳转又点了一次第二次是网关侧配置的超时重试前一个线程处理慢了网关自动重发了同一份请求体。这类问题在分布式系统里实在太常见了根因并不是某个组件坏了而是接口没做幂等处理。所谓幂等性用大白话说就是同一个请求不管执行一次还是执行一百次对系统状态产生的影响都必须一模一样。就像电梯按钮你连续按十次电梯也不会为你派十台过来。事故里的三条重复路径我后来总结成一张排查清单遇到类似问题基本可以直接套用前端重复提交按钮没置灰、JS没做防重、框架或网关的自动重试Feign、OkHttp、Nginx层的超时重发、消息队列的重复消费MQ的at-least-once投递语义决定了消息可能被消费多次。这三条路只要中一条后端接口没幂等就有概率产生脏数据。1.2 幂等性一个请求执行一百次效果只能有一次很多刚接触这个概念的同学会把幂等和并发控制搞混。并发控制解决的是“同一时刻多个请求同时改一个资源”的竞争问题而幂等解决的是“同一个请求被反复提交多次”的重复处理问题。两者有交集但目标完全不同。一个接口可以既做并发控制又做幂等处理但判断是否做好了要看重复请求返回的结果和首次成功时是否一致。我用生活化的方式再解释一下幂等。你的门禁卡刷一次门开刷十次门也是开着的状态不会因为多刷几次就多开一扇门。反过来如果你去自助贩卖机投币买水投一次币出一瓶水投十次币理论上要出十瓶水这个操作就不是幂等的。接口幂等设计的本质就是让系统对各种“重复动作”保持稳定不产生额外副作用。2. 哪些接口必须做幂等读接口、写接口、回调接口判断标准2.1 纯查询接口天生幂等但别忽视缓存压力查询接口通常不需要做幂等设计因为GET请求本身不修改系统状态查多少次结果都一样。但我要提醒一个容易被忽略的问题如果查询接口背后关联了复杂的聚合计算并且在重复请求场景下会反复触发计算和数据源压力那这个接口即使不幂等也要通过缓存把压力挡掉。举个例子一个订单详情查询接口如果每次查询都直接查数据库并实时汇总用户的多笔支付流水用户刷新一次就多一次数据库查询。高并发情况下被反复点刷新数据库连接池很容易被打满。这种场景下我一般会加一层本地缓存或Redis缓存设置合理的过期时间避免同一个请求的重复查询把后端打垮。2.2 写接口的分级不是所有写操作都需要幂等写操作需要分情况讨论不能无脑全上幂等。我习惯把写接口分成三类来评估风险第一类是纯新增操作比如用户创建订单、上传文件。这种操作的每次执行都会产生一条新数据如果没有自然唯一键或业务唯一键重复提交的直接后果就是出现多条重复记录风险最高必须做幂等。第二类是覆盖式更新比如用户修改个人信息同一个请求执行两次结果仍然是覆盖成同样的值天然具备幂等性一般不需要额外处理。第三类是状态流转类更新典型的就是订单从“待支付”流转到“已支付”从“已支付”流转到“已发货”。这种操作最危险因为重复执行很可能导致状态被错误地二次流转比如一笔订单被重复通知两次“支付成功”如果没有判断当前状态就可能重复发货。我用一张表把这三种情况整理了一下方便你对照自己的业务判断写操作类型是否天然幂等风险等级处理建议纯新增无唯一键否高必须有幂等键建议用唯一索引兜底纯新增有业务唯一键部分中靠唯一键捕获重复捕获后返回原结果覆盖式更新是低无需特殊处理必要时乐观锁即可状态流转更新否高必须用状态机或乐观锁限制流转条件金额累加/扣减否极高必须做强幂等分布式锁对账兜底2.3 支付回调与异步通知幂等是硬性要求支付回调、第三方异步通知这类场景幂等不是可选项而是硬性要求。像微信支付、支付宝的异步通知官方文档里写得很明确通知可能多次发送商户系统必须能够正确处理重复通知。而且通知的重试间隔可能是15秒、15秒、30秒、3分钟、10分钟、20分钟、30分钟等递增的如果接口没做幂等一次回调重试就够把订单状态搞乱了。这类接口的幂等键设计也有套路。绝对不能直接用请求里的随机字符串做幂等键而是要用业务唯一标识比如订单号、支付流水号。因为同一笔支付的回调通知虽然每次请求参数可能带不同的随机值但业务上对应的还是同一笔订单。用订单号或支付流水号做幂等键才能保证重复通知被正确识别。3. 五种主流幂等方案对比我们最终选了 Token 状态机组合3.1 数据库唯一索引最简单但要处理好异常数据库唯一索引是最常见的幂等方案实现成本低直接把某个业务字段设为唯一索引比如订单号、支付流水号、幂等键。重复插入时数据库会抛DuplicateKeyException捕获到这个异常就能判断是重复请求。但这里有个关键细节不能只把唯一索引当作保护层还要在捕获到重复异常后返回首次请求的成功响应而不是直接报错或提示失败。否则用户侧看到的是“下单失败”但实际订单已经创建了体验非常糟糕。另外要注意唯一索引方案在高并发下会有一个小问题首次插入和业务执行之间如果业务逻辑本身执行时间较长重复请求会一直阻塞在插入等待上直到第一个事务提交或回滚。这个阻塞本身不是坏事但会占用数据库连接。所以唯一索引一般适合作为最终兜底而不是主力处理层。3.2 乐观锁更新适合状态流转场景乐观锁方案一般通过版本号实现。表中加一个version字段更新时带上条件where id? and version?如果更新影响行数为0说明版本已经变了这个请求要么是重复的要么是基于过期状态的无效操作。这种方案在状态流转类接口里非常好用。比如订单从“待支付”到“已支付”的更新SQL可以写成update t_order set statusPAID, versionversion1 where order_no? and statusPENDING and version支付时的快照版本。如果更新的影响行数为0就说明当前订单已经不在“待支付”状态重复的支付回调直接被忽略。乐观锁的优点是轻量、没有额外存储成本缺点是无法拦截所有类型的重复请求。比如两个线程都基于同一版本读取数据但一个在更新另一个也在尝试更新只有第一个会成功这个语义完全符合状态流转的需求。3.3 Token 机制用预生成令牌挡住重复提交Token机制的核心思路是在业务请求真正执行前服务端先给客户端发一个唯一令牌客户端提交业务请求时必须携带这个令牌。服务端收到业务请求后先校验令牌是否存在存在则删除令牌并继续执行不存在则拒绝请求。这个方案特别适合“提交订单”这类操作。用户在进入下单页面时前端先向后端要一个token后端把token存到Redis并设置过期时间。用户点击提交时带上token后端拿到token后执行Redis的DEL操作如果删除成功说明令牌有效且是首次使用如果删除失败说明令牌已经被用过或者是伪造的。Token机制最大的优势是能前置拦截重复提交不必等请求进了业务逻辑才判断。缺点是给了攻击者提前获取token的机会而且如果用户拿到token后一直不提交token会过期需要重新获取。3.4 分布式锁与 SETNX轻量但要注意持有时间分布式锁方案通常用Redis的SETNX命令实现对一个幂等键执行SETNX如果设置成功说明是首次请求可以执行业务如果设置失败说明有请求已经在处理直接返回重复或等待。这种方案适合对“大量并发请求都指向同一个资源”做保护但有个非常容易踩的坑锁的过期时间必须大于业务的最大执行时间。如果业务执行要3秒锁只设了1秒过期锁自动释放后第二个请求又进来了之前那个还没执行完就会造成两个请求同时处理同一笔业务。我在实际应用里见过不止一次这样的线上问题最后总结出一个处理思路锁过期时间要按业务的P99耗时再乘一个系数来设置同时要在业务执行完后主动释放锁。如果真的遇到超长业务可以考虑用看门狗机制自动续期。但也要清醒分布式锁本身不是完整的幂等方案它只是保证了同一时刻只有一个请求在执行如果有两个请求先后执行同一个操作锁释放后的第二次请求仍然是重复请求。3.5 组合方案的协同逻辑与适配原因我们在最终落地时没有依赖单一方案而是做了组合Token机制拦截重复提交 状态机限制状态流转 数据库唯一索引做最终兜底。为什么要组合因为单一方案都有盲区。Token机制能挡住用户重复点击但如果前端没有正确传递token或者重复请求绕过了token校验层那还是要靠状态机来保证状态不会乱。状态机流转判断能挡住基于错误状态的重复操作但如果两个请求同时到达状态机的条件判断可能同时通过这时候就需要数据库唯一索引或分布式锁做硬性兜底。所以我的建议是不要追求找到一个万能方案而是要想清楚你的系统里每一层重复请求分别从哪里来然后选一个主方案和两个兜底方案。主方案负责挡住大部分重复请求兜底方案负责在极端情况发生时不至于产生脏数据或资金损失。4. 落地方案幂等控制层的设计与实现细节4.1 幂等记录表与缓存的数据结构设计我们最终实现的幂等控制层核心是由一张幂等记录表和一套Redis缓存组成的。表结构设计上我建议至少包含这些字段idempotent_id全局唯一幂等键、biz_type业务类型比如订单、支付、biz_no业务单号、status处理状态、request_body原始请求体、response_body首次成功的响应体、create_time和update_time。这里有一个经常被忽略的字段request_body和response_body。把它们存下来有两个好处第一当重复请求到来时可以直接返回之前保存的响应体保证重复请求和第一次请求看到的结果完全一致第二线上排查问题时可以通过记录里的请求体快速定位出到底是哪个环节重放了请求。Redis缓存则用来做主流程判断。key的设计我一般用幂等键本身value存处理状态同时设置一个合理的过期时间。这里有个经验值供参考过期时间必须大于业务的最长处理时间同时小于幂等记录表的保留周期。我们线上设置的是24小时因为我们的业务在24小时内重复通知的概率非常低而超过24小时后即使有重复请求也可以通过查数据库幂等记录来判断。4.2 核心流程先查幂等表再执行业务最后回写结果整个幂等控制层走的是一个三段式流程先查幂等判断再执行业务逻辑最后回写处理结果。这个过程听起来简单但每一步都有容易踩坑的细节我逐个说。第一步请求进来后先根据幂等键查询Redis。如果Redis中存在且状态为“处理中”或“成功”直接把之前保存的响应体返回无需继续往下走。如果Redis中不存在说明可能是首次请求也可能是缓存过期了需要继续查数据库幂等表来确认。第二步查数据库幂等表。如果存在记录说明是重复请求把数据库里存的response_body返回如果不存在说明是首次请求执行真正的业务逻辑。但这里有个并发问题两个完全相同幂等键的请求同时进来都发现Redis和数据库里没有记录就会同时执行两次业务逻辑。要防止这种情况需要引入数据库唯一索引或分布式锁保证只有一个请求能成功插入幂等记录另一个请求会插入失败并进入重复处理分支。第三步业务执行完成后更新幂等记录表的状态为“成功”把请求体和响应体写进去同时更新Redis缓存。如果业务执行失败则删除幂等记录或把状态置为“失败”让后续重试请求可以重新执行业务。4.3 代码实现Java Redis MySQL 的简化示例光讲原理不够直观我写一个简化版的Java实现代码逻辑做了裁剪但核心处理分支是完整的你可以根据自己项目的基础框架做适配public class IdempotentHandler { private final StringRedisTemplate redisTemplate; private final IdempotentRecordMapper idempotentRecordMapper; public IdempotentResult handle(String idempotentId, Runnable businessLogic) { // 步骤1查Redis命中直接返回 String cached redisTemplate.opsForValue().get(idem: idempotentId); if (cached ! null) { if (SUCCESS.equals(cached)) { return new IdempotentResult(false, getRecordResponse(idempotentId)); } throw new BusyException(重复请求正在处理中请勿重复提交); } // 步骤2尝试插入幂等记录利用唯一索引防止并发穿透 IdempotentRecord record new IdempotentRecord(); record.setIdempotentId(idempotentId); record.setStatus(PROCESSING); try { idempotentRecordMapper.insert(record); } catch (DuplicateKeyException e) { // 说明另一个请求先插入了记录本请求属于重复请求 return new IdempotentResult(false, getRecordResponse(idempotentId)); } // 步骤3预写Redis标记处理中防止后续请求穿透到DB redisTemplate.opsForValue().set(idem: idempotentId, PROCESSING, Duration.ofMinutes(10)); try { businessLogic.run(); // 步骤4更新DB状态为成功并保存响应体 record.setStatus(SUCCESS); record.setResponseBody({\code\:0,\msg\:\success\}); idempotentRecordMapper.updateById(record); redisTemplate.opsForValue().set(idem: idempotentId, SUCCESS, Duration.ofHours(24)); return new IdempotentResult(true, null); } catch (Exception e) { // 业务失败删除幂等记录和缓存让后续重试能重新执行 idempotentRecordMapper.deleteById(idempotentId); redisTemplate.delete(idem: idempotentId); throw e; } } }注意步骤2加的唯一索引是关键兜底。如果担心Redis和数据库的状态不一致可以在步骤3之后定期做一个异步校验把处理中状态过久的数据捞出来做补偿。这套方案整体下来重复请求的拦截率和正确性都很高。4.4 上线前压测用并发工具验证重复请求只成功一次写完之后不能直接上线一定压测。我习惯用JMeter模拟同一幂等键的高并发请求验证不管并发数是多少最终数据库里只产生一条有效记录且所有请求拿到的响应一致。压测时要关注的几个指标第一接口的最大响应时间Token查询和Redis操作不能成为瓶颈第二重复请求的比例正常情况下应该趋近于100%的重复请求都被拦截第三数据库幂等表的并发插入情况要确保唯一索引不会成为热点瓶颈。之前有一次压测我们模拟了200个并发请求全部使用同一个幂等键发现数据库层面没有任何问题但Redis的写入压力很大每个请求都在先查后写产生了很多无意义的Redis操作。后来我调整了流程只有数据库插入成功的请求才去写Redis其他重复请求直接查数据库返回。这样Redis的写量明显下降整体吞吐提升了不少。5. 实测中踩过的真实坑从竞态到重试风暴5.1 缓存过期与超长业务执行的竞态问题这套方案上线后遇到的第一个坑就是Redis缓存过期时间和业务执行时长的竞态。有个用户提交订单业务逻辑要执行8秒但我们对“处理中”状态设置的过期时间是10分钟覆盖8秒其实绰绰有余。问题出在另一个场景业务执行过程中调了外部接口外部接口卡住了导致业务执行了20分钟代价就是“处理中”的缓存过期了重试请求穿透到数据库发现幂等记录状态还是“处理中”于是直接返回“重复请求正在处理中请勿重复提交”。这个结果不算错误但会让用户端看到的报错非常不解明明只是点了一下按钮怎么提示“正在处理中”呢后来我们是这么处理的把状态为“处理中”的记录在Redis过期后主动返回“处理中”的提示而不是“重复提交”同时增加一个后台定时任务把超过10分钟还处于“处理中”的幂等记录捞出来人工标记为“超时失败”让用户可以重新提交。5.2 幂等表和业务表的原子性难题另一个深刻的坑是幂等记录表和业务表之间的原子性问题。我们的流程是先插入幂等记录再执行业务最后更新幂等记录状态。如果业务执行成功但更新幂等记录状态时数据库刚好出问题就会出现业务数据已经写入了但幂等记录仍是“处理中”下一次重试进来就会认为“处理中”而拒绝执行结果就是订单创建成功但用户收到的是“处理中”的提示。这个问题本质上是分布式事务一致性问题。当时我们用了两个手段来解决第一幂等记录表的状态由“处理中”到“成功”的更新操作和业务表的关键写入放在同一个本地事务里比如下单场景把幂等记录成功状态写入和订单创建放到一个事务里要么都成功要么都回滚第二对实在无法放在同一个事务的业务比如调用了外部接口增加“人工重放补偿”的后台系统扫描长时间处于“处理中”的记录根据业务单号反查业务表如果业务数据已经存在就直接把幂等记录标记为成功。5.3 重试风暴上游三次重试叠加导致服务打垮重试风暴这个问题是我们在接入某个网关层组件后暴露出来的。当时网关配置了超时重试从客户端到网关再到后端每一层都有重试机制结果同一个请求在链路里最多可能被放大成六次请求。如果这六次请求都打到幂等控制层虽然不会产生脏数据但会把服务资源白白耗掉。尤其是订单服务这种高并发入口一个用户的请求被重试成六次整体的大促流量可能变成六倍服务很容易被拖垮。我们当时的处理是在网关层关闭自动重试关闭不了的就设置重试次数为0在上游服务里关闭Feign的重试把重试策略改为只针对特定错误码重试。幂等控制层能拦截重复请求但不应该成为重试风暴的牺牲品。这里也想提醒大家做幂等设计时不要只盯着接口本身更要看整个调用链路上每一层各自配置了什么重试策略。幂等是保障数据正确性的底线但重试风暴带来的性能问题单靠幂等是扛不住的。5.4 热点幂等键引发的缓存穿透我们线上有一个场景同一个用户短时间内会对同一个订单发起多次重复请求这就形成一个热点幂等键。如果缓存中这个key不存在比如正好过期了所有重复请求就会同时穿透到数据库幂等表查询瞬间把数据库打出一波峰值。这个问题的解法有几种。第一种是对热点幂等键的本地缓存在JVM进程内缓存一份最近的幂等结果缺点是多个实例之间数据不一致可能误判第二种是给Redis的key设置更长的过期时间减少穿透窗口第三种是预热当某个幂等键被第一次成功处理后主动把这个key的过期时间延长。我们最终结合了第二和第三种同时把底层的数据库查询加了限流和熔断保护。5.5 幂等命中日志被低估的监控价值很多团队把幂等命中当作一个简单的返回完全没有监控它。但幂等命中日志的价值非常高。如果一个接口的幂等命中率突然升高往往意味着上游发生了重试风暴或者有客户端在异常重放。大促期间我盯过一个关键指标支付回调的幂等命中率。正常情况下支付回调的重复通知比例在5%左右如果这个比例突然飙到30%基本可以断定是支付渠道或我们自己的通知消费链路出了问题。所以我强烈建议幂等控制层一定要打点记录三件事命中幂等返回的请求数、实际执行业务的请求数、幂等记录状态异常的请求数。这三组数据放到监控面板上配合告警阈值能帮你提前发现很多潜在故障。6. 边界思考不是所有系统都要上强幂等6.1 高吞吐场景下放弃部分幂等的理由聊完幂等的实现和坑我想再说一个被很多人忽略的问题不是所有场景都适合做强幂等。有些超高吞吐的内部异步处理链路比如日志收集、埋点上报、非核心统计数据的聚合如果也全部做幂等成本反而可能高于收益。这个场景下我会选择允许少量重复通过下游的最终一致性处理来兜底。做这个判断之前我会问自己两个问题重复数据是否会造成资金损失或严重的数据错误重复处理带来的成本增加是否在可控范围内如果两个答案都是“否”或“可控”我通常会选择更轻量的方案比如只做简单的内存去重或者干脆不做把有限的资源留给真正需要保护的场景。还有一个中间态思路对重复不敏感的场景可以用at-most-once语义。也就是消息队列消费时消费成功后立即确认消息宁可偶尔丢一条也绝不重复处理。这个策略适合那些重复数据的害处大于消息丢失的场景。6.2 幂等、分布式事务与对账兜底的层级关系最后聊聊幂等在分布式系统里的位置。很多人把幂等当成解决一切分布式一致性问题的银弹这是个误区。幂等解决的是“重复请求”的问题分布式事务解决的是“多个服务之间数据一致性”的问题两者是一个层级关系就像地基和楼房幂等是地基的一部分但光有地基房子是盖不起来的。以支付系统为例即使支付回调接口做了完美的幂等处理如果内部还有“扣减余额”“增加积分”“更新优惠券状态”等多个系统协作每个子系统的调用顺序或事务边界不一致仍然可能出现余额扣了但积分没加这类问题。这种情况下幂等只能保证“这个请求重复执行不会产生更多脏数据”但无法保证多个系统之间的数据最终一致。所以我们在设计核心资金链路时会同时做三件事链路内的每个写接口都做幂等、链路之间使用事务消息或本地消息表保证可靠投递、定期跑批对账检查业务数据与流水的一致性。对账是最后一道防线哪怕前面的幂等和事务都出了问题对账也能在T1发现差异人工介入修正。这个理念我一直很推崇不要假设前面的每一层都完美而是假设每一层都有出错的概率然后层层设防。最后再分享一点长期实践下来的个人体会。每次接到新需求我第一件事不是画架构图而是先问这个接口会不会被重复调用重复调用会有什么后果。养成这种思维习惯后你会发现很多线上事故是可以在设计评审阶段就避免的。幂等设计不是一个一次性上线的工作它是分布式系统长期稳定运行的底层地基之一。我们团队后来把幂等控制做成了统一的公共组件所有写接口接入时强制走一遍这套流程。刚开始还会有人觉得啰嗦但半年后回看这套组件至少帮我们挡住了十几次潜在的重试和重复消费事故。如果你所在的项目还没有这样的沉淀我真心建议尽早补上这一课。