用户提交按钮连点两次、前端超时重试、消息中间件重复投递——这三类问题几乎是每个后端开发都会遇到的场景。SpringBoot接口防抖和接口幂等性本质上都是在解决“同一个请求被执行了多次”的隐患但两者的侧重点不一样。防抖更偏向“拦截”幂等更偏向“允许重复但结果一致”。这篇文章我会从这两个概念出发结合SpringBoot生态给出可落地的方案包括注解AOP实现请求锁、Redis分布式防抖、Token机制、数据库唯一约束兜底以及实际项目中踩过的坑。适合那些写接口但还没系统做过重复提交防护的同学也适合想优化现有接口健壮性的团队。1. 先搞清楚防重复提交和接口幂等性真的是同一个东西吗很多人把这两个词混着用面试的时候也经常被问懵。实际上它们有交集但不是一回事。1.1 防重复提交的本质是“拦截”防重复提交英文一般叫Repeat Submit Prevention核心思路很简单在短时间内如果系统识别到同一个请求来源在重复提交同样的内容就直接拒绝后面的请求只放行第一次。最典型的场景就是用户下单。用户在支付页面手抖点了一下“提交订单”按钮还没反应过来又点了一下。如果前端不做按钮loading处理后端也不做任何防护这两个请求很可能都会到达服务端最终的结果就是生成了两笔一模一样的订单。用户莫名其妙多付了一单钱客服那边得多处理一个退款工单整个链路的体验都会受影响。防重复提交的特点是“时间敏感”它要求的是“窗口期内的唯一性”。比如3秒内同一个用户、同一个接口、同样的参数只能成功一次。窗口期过后同样的请求又可以正常提交了。这种机制适合操作类接口比如提交订单、提交表单、发送验证码。1.2 接口幂等性的本质是“可重放”接口幂等性英文是Idempotency它比防重复提交的要求更严格。幂等的意思是同一个请求无论执行一次还是执行多次最终的结果都是一样的而且不会产生副作用。举个例子。支付回调接口每次用户支付成功后微信或支付宝都会发一个异步通知到你的回调地址。如果网络抖动回调通知可能发很多次而且顺序还可能乱。如果你的回调接口不是幂等的每收到一次通知就更新一次订单状态、加一次用户余额那这用户的余额可能翻了几倍都不止。幂等接口的典型设计思路是允许重复调用但系统要有能力识别出“这个请求我已经处理过了”然后直接返回之前的结果或者在逻辑上保证重复执行不会产生额外影响。它关注的是“业务结果的一致性”而不是“请求是否被拦截”。1.3 从用户场景倒推需求我在实际项目里通常会问自己几个问题来倒推需求这个接口被重复调用的概率有多大如果只是用户手抖防抖就够了。如果可能被消息系统重放就必须做幂等。重复调用会造成什么后果只是重复发送一封邮件影响很小。导致订单重复创建、库存超卖那就是事故了。系统是单机部署还是多机部署单机可以用本地缓存做防抖多机必须用Redis等分布式组件。理解这些区别之后再去看具体的实现方案思路会清晰很多。下面我会从最简单的单机方案开始逐步过渡到分布式场景最后再讲业务层的幂等设计。2. 轻量级方案基于ConcurrentHashMap的请求锁如果你的项目还处在单体应用阶段部署规模也就一两台机器接口的并发量也不是特别高那完全可以用一个轻量级的本地缓存方案来实现接口防抖。不需要引入额外的中间件一个自定义注解加一个AOP切面就够了。2.1 方案原理与适用场景核心思路是用ConcurrentHashMap保存请求的唯一标识和第一次到达的时间戳。后续请求到达时先从Map里查一下如果发现同样的请求在窗口期内已经出现过直接拒绝或返回重复提交的提示。窗口期过后再把记录移除。这个方案的特点是零依赖、实现简单、性能极高。ConcurrentHashMap的读写性能在本地缓存里算是非常优秀的适合接口QPS在几百到几千这个量级的场景。但它有一个硬伤只对单机有效。如果服务部署了多个实例每个实例都有自己的ConcurrentHashMap那负载均衡把请求分发到不同机器上时每台机器都会认为自己是第一次接收到这个请求防抖就失效了。另外本地缓存重启即丢失如果服务在窗口期内发生了重启之前的防抖记录就没了。所以这个方案真正的适用场景是个人项目、内部管理系统、工具类接口、以及明确知道服务只会单点部署的项目。2.2 核心代码实现首先是自定义注解这个注解要加在Controller的方法上用来标记哪些接口需要防抖Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface NoRepeatSubmit { /** * 防抖时间窗口单位秒默认3秒 */ int interval() default 3; /** * 窗口期内重复请求的提示信息 */ String message() default 操作太频繁请稍后再试; }然后是AOP切面。这里的关键是生成请求的唯一标识我常用的做法是用户标识 接口路径 去重后的参数列表。这样能最大程度上识别“同一个用户对同一个接口提交了相同参数”的请求。Aspect Component public class NoRepeatSubmitAspect { private static final MapString, Long REQUEST_CACHE new ConcurrentHashMap(); Around(annotation(noRepeatSubmit)) public Object around(ProceedingJoinPoint joinPoint, NoRepeatSubmit noRepeatSubmit) throws Throwable { // 生成请求唯一标识 String key buildRequestKey(joinPoint); long now System.currentTimeMillis(); long intervalMillis noRepeatSubmit.interval() * 1000L; // 原子性检查并写入 Long firstTime REQUEST_CACHE.putIfAbsent(key, now); if (firstTime null) { // 首次请求正常放行 return joinPoint.proceed(); } // 窗口期内重复请求直接拒绝 if (now - firstTime intervalMillis) { throw new RuntimeException(noRepeatSubmit.message()); } // 窗口期已过更新记录并放行 REQUEST_CACHE.put(key, now); return joinPoint.proceed(); } private String buildRequestKey(ProceedingJoinPoint joinPoint) { // 实际项目中这里应该从请求上下文获取用户ID String userId anonymous; String methodName joinPoint.getSignature().toLongString(); Object[] args joinPoint.getArgs(); String paramStr args null ? : Arrays.stream(args) .map(arg - JSON.toJSONString(arg)) .sorted() .collect(Collectors.joining(,)); return userId # methodName # paramStr; } }2.3 这个方案有哪些坑这个方案跑起来很容易但要用得稳有几个细节必须注意。参数序列化的问题。如果接口参数里包含随机值比如UUID、时间戳那每次请求的参数串都不一样防抖就失效了。反过来如果参数里有大字段比如富文本内容、Base64图片那序列化出来的key会非常长既浪费内存又降低匹配效率。更合理的做法是只提取必要的业务字段做key比如订单号、手机号、商品ID。Map的内存泄漏问题。ConcurrentHashMap只进不出如果窗口期过后没有清理机制长期运行下来会占满内存。上面的代码里我通过“窗口期后更新记录”来复用key但实际上每个唯一请求都会留下一个key。一个更完善的做法是定期清理过期记录或者用Guava的Cache来实现自动过期。我个人在实际项目中更推荐用com.google.common.cache.Cache替换ConcurrentHashMap代码量几乎一样但会获得自动过期的能力private static final CacheString, Long REQUEST_CACHE Caffeine.newBuilder() .expireAfterWrite(5, TimeUnit.SECONDS) .maximumSize(10_000) .build();Caffeine的expireAfterWrite刚好配合防抖窗口期使用缓存到期自动清除不需要手动清理。这个细节虽然小但能避免线上OOM的隐患。3. 分布式落地基于Redis的防抖方案一旦服务进行了多实例部署本地缓存方案就彻底不够用了。这个阶段最常规的做法是把“防抖记录”从JVM内存搬到Redis里用Redis的原子操作保证所有实例看到的是同一份数据。3.1 为什么必须有RedisRedis提供的关键能力是SET NX EX指令。NX表示只有当key不存在时才设置成功EX表示设置过期时间。这两个参数组合起来天然就能实现“在窗口期内第一次能写进去后续写不进去”的防抖逻辑。这个操作是原子的所以不会出现并发下两个请求同时写入成功的问题。而且Redis本身是高可用的即便某个实例宕机只要Redis集群还活着防抖能力就不会丢失。相比JVM本地缓存Redis方案对多实例部署、甚至微服务架构都是友好的。这里要说明一下Redis防抖方案适用于大多数业务场景但它会引入一次额外的网络IO。如果接口本身性能瓶颈就很大或者对延迟极其敏感那就需要权衡一下是否要引入Redis。3.2 Redis防抖的完整实现基于Redis的实现核心逻辑依然是注解加AOP只是把存储层换成了Redis。先看注解跟上文基本一致只是多了一个可以自定义key前缀的参数Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface NoRepeatSubmit { /** * 防抖时间窗口单位秒 */ int interval() default 3; /** * 自定义key前缀避免不同接口的key冲突 */ String keyPrefix() default ; String message() default 操作太频繁请稍后再试; }AOP切面里使用Spring Data Redis的StringRedisTemplate执行setIfAbsent操作Aspect Component public class RedisNoRepeatSubmitAspect { private final StringRedisTemplate redisTemplate; public RedisNoRepeatSubmitAspect(StringRedisTemplate redisTemplate) { this.redisTemplate redisTemplate; } Around(annotation(noRepeatSubmit)) public Object around(ProceedingJoinPoint joinPoint, NoRepeatSubmit noRepeatSubmit) throws Throwable { String key buildKey(joinPoint, noRepeatSubmit); long intervalSeconds noRepeatSubmit.interval(); // setIfAbsent对应SET NX EXkey不存在时设置成功并返回true Boolean success redisTemplate.opsForValue() .setIfAbsent(key, 1, Duration.ofSeconds(intervalSeconds)); if (Boolean.TRUE.equals(success)) { // 第一次请求正常处理 return joinPoint.proceed(); } // 重复请求直接拒绝 throw new RuntimeException(noRepeatSubmit.message()); } private String buildKey(ProceedingJoinPoint joinPoint, NoRepeatSubmit noRepeatSubmit) { String userId getCurrentUserId(); String methodName joinPoint.getSignature().toLongString(); String paramStr buildParamKey(joinPoint.getArgs()); // key结构namespace userId method params String prefix StringUtils.hasText(noRepeatSubmit.keyPrefix()) ? noRepeatSubmit.keyPrefix() : nrs; return prefix : userId : DigestUtils.md5DigestAsHex((methodName paramStr).getBytes()); } }这里有几个细节要展开说明。第一个是setIfAbsent和expire的原子性问题。很多初学者会先setnx再单独调expire如果中间服务宕机了Redis里就会留下一个永远不过期的key后续所有请求都会被拦截。Spring Data Redis的setIfAbsent(key, value, timeout)方法把设置值和过期时间封装成了一个原子操作用这个就对了。第二个是返回值的判空处理。setIfAbsent返回的是Boolean正常情况下不会是null但为了保险起见我用Boolean.TRUE.equals(success)来判断避免因自动拆箱导致NPE。第三个是key的结构设计。我习惯把用户标识放在key中间这样Redis里的key分布会比较分散不容易出现热点key。MD5是避免参数串过长导致key占用太多内存。3.3 关键设计请求指纹的生成策略这一节值得单独拿出来说因为Redis防抖最常见的失效原因就是请求指纹生成得不对。请求指纹也就是我上面代码里的buildParamKey方法负责把请求参数规范化成一个唯一字符串。这个设计有两个极端需要避免一个极端是太敏感。把请求头里的随机token、时间戳、每次都会变的traceId都放进指纹里那同一个用户两次提交同样的表单指纹却不一样防抖直接失效。另一个极端是太粗糙。只取接口路径和方法名作为指纹那用户A提交和用户B提交会被认为是同一个请求后面的用户就会被误拦截。这属于误伤。正确的做法是把请求参数按字段名排序只选择参与业务唯一性判定的字段。比如提交订单接口参与判定的字段应该是商品ID、数量、收货地址ID用户登录接口参与判定的字段应该是手机号或用户名。有些字段天然不适合做幂等判断比如页面停留时间、前端埋点数据。对于字符串拼接的顺序我可以多强调一句一定要先排序再拼接。如果两个请求的参数是“a1b2”和“b2a1”业务上明明是同一个请求但如果不排序指纹就不一样了。用JSON序列化后排序或者用TreeMap按key排序后再拼接都能解决这个问题。3.4 注意Redis端的时间窗口与锁过期Redis防抖方案还有一个容易踩坑的地方锁过期时间与业务执行时间的关系。假如你设置了3秒的防抖窗口期但接口处理一次就要5秒。第一个请求进去处理了3秒后Redis里的key过期了第二个请求此时到来发现key不存在又成功写入了于是两个请求同时处理同样的业务防抖失效。处理这个问题有几个思路把防抖窗口期调大至少要大于接口的最坏执行时间。在业务执行完毕后主动删除Redis里的key释放窗口。如果业务执行时间和窗口期冲突很大就需要考虑换用分布式锁方案而不是简单的防抖。第一种方式最简单但需要你对接口的响应耗时心里有数。第二种方式更精确但也有风险如果业务方法抛异常了key删不删删了用户重试后还能再提交不删用户就只能等窗口期结束。这需要在业务上达成共识。我一般会建议用第一种方式把窗口期稍微放宽一点比如接口一般100毫秒执行完窗口期设2秒已经绰绰有余了。另外Redis如果挂了所有接口的防抖都会失效。如果你的系统对防抖有强要求那Redis的高可用必须纳入考量。如果Redis只是临时不可用接口应该降级为放行还是拦截我倾向于放行因为防抖的目的是防止重复提交而不是阻塞正常业务。即使防抖失效导致少量重复请求进入后面还有业务层的幂等做兜底。4. 业务级幂等从接口层防抖到数据层兜底防抖是在接口层面做拦截解决的是“不该重复的请求不让它进来”。但真正要做到万无一失光靠防抖是不够的。接口可能被恶意刷防抖可能被绕过Redis可能抖动网络重试可能发生在任何节点。这时候就需要业务层的幂等设计来兜底。4.1 Token令牌机制最经典的“一单一令牌”方案Token机制是解决重复提交最经典的模式很多下单流程都在用。它的流程是这样的前端在打开下单页面时先调用后端接口获取一个一次性的token。后端把这个token存到Redis里设置一个合理的过期时间比如10分钟。前端带着这个token去提交订单。后端收到请求后先检查Redis里有没有这个token有就删除并继续处理没有就返回“重复提交”。token机制的精髓在于“先删除再处理业务”。这里不用先查后删的顺序因为“查”和“删”之间有一段时间窗口并发下两个请求都可能查到token存在然后都进入业务处理。直接用RedisTemplate.delete(key)的返回值判断是否删除成功删除成功就是拿到了令牌删除失败说明令牌已经被别人用了直接拒绝。public boolean tryAcquireToken(String token) { // 删除成功说明是第一次使用删除失败说明token不存在或已使用 return Boolean.TRUE.equals(redisTemplate.delete(token)); }这个方案唯一要注意的是token的获取和提交必须配套。如果页面刷新了token要重新获取旧token要作废。如果token过期了前端要能正确处理提示用户刷新页面重新获取。4.2 数据库唯一约束最刚性的幂等兜底如果说接口层的防抖是“软防御”那数据库的唯一约束就是“硬防御”。一旦唯一约束建立起来不管请求重复多少次数据库层面都只能插入一条记录这是最可靠的兜底手段。最常见的应用场景是订单表里建立一个业务订单号biz_order_no的唯一索引。支付回调时回调接口拿到的订单号是幂等键先尝试插入一条回调记录如果插入失败说明这个回调已经处理过了直接返回成功。这样即使上游疯狂重试也不会重复处理业务。这里有一个并发插入唯一键冲突时要注意的问题。当两个请求同时插入同一个唯一键时只有一个能成功另一个会抛出DuplicateKeyException。不要用try-catch捕获这个异常当作业务失败来处理应该捕获后返回“已经处理过了”的幂等响应。try { paymentRecordDao.insert(record); } catch (DuplicateKeyException e) { // 已处理过直接返回成功 return Result.success(重复回调已忽略); } // 继续业务处理表结构设计上我建议把确认记录和业务更新放在同一个事务里并且事务隔离级别要设置合理避免死锁问题。4.3 乐观锁与状态机校验乐观锁是处理更新场景幂等性的常用手段核心思想是在更新时校验数据的版本号或状态只有版本匹配时才允许更新。比如用户修改订单地址订单表里有一个version字段初始值是0。更新语句只允许在version等于传入值时执行UPDATE orders SET address #{newAddress}, version version 1 WHERE id #{orderId} AND version #{oldVersion}如果更新影响的行数等于0说明版本不匹配数据已经被别人改过了这次更新应该拒绝。状态机校验是另一种思路。比如订单状态从“待支付”只能流转到“已支付”从“已支付”只能流转到“已发货”。在更新时加一个WHERE status 待支付的条件如果状态已经变成“已支付”了更新就不会成功。这天然就保证了“一个订单只能支付一次”的幂等性。这两种方式各有适用场景乐观锁适合高并发下对同一资源的更新状态机校验适合业务流程状态流转明确的场景。两者也可以结合使用更新语句里同时带version和status条件防护力度更强。4.4 消息消费场景的幂等处理如果你的系统接了消息队列比如RocketMQ或RabbitMQ那消息重复消费也是必须处理的场景。消息中间件通常提供“至少一次”的投递保证意味着极端情况下消息会重复投递。常规解决方案是消费记录表。设计一张消息消费记录表以消息体里的业务唯一ID作为主键CREATE TABLE msg_consume_log ( msg_id VARCHAR(64) PRIMARY KEY, consume_time DATETIME NOT NULL ) ENGINEInnoDB;消费者收到消息后先尝试插入msg_consume_log。插入成功说明这条消息是第一次消费继续执行业务逻辑。插入失败说明已经消费过了直接跳过。这里有个细节插入消费记录和执行业务逻辑必须在同一个事务里否则会出现“记录插入成功但业务没执行”或者“业务执行了但记录没插入”的不一致状态。如果用的是Spring的Transactional把insert和业务处理放在同一个方法里就行了。还有一点如果消息里的业务ID为空或重复这个方案就失效了。所以消息生产方在组装消息时必须保证携带一个稳定的业务唯一ID。5. 常见问题与排查技巧实录最后这一部分我把自己在项目中实际踩过的坑、排查思路整理出来做成一个速查表。这些问题如果没有经历过排查起来会走很多弯路。5.1 防抖不生效的排查清单遇到防抖不生效第一反应不是怀疑Redis或AOP而是先确认请求指纹是不是每次都不一样。排查顺序我建议是这样的确认注解是否真的加到了目标方法上。加在Controller方法上和加在Service方法上AOP切入点不同效果完全不同。确认参数序列化是否稳定。如果参数里有Map而Map的迭代顺序每次都不一样那序列化出来的字符串就不同。对Map排序或改用LinkedHashMap可以解决。确认key是否包含用户标识。如果两个用户共享相同的key可能导致互相误伤。确认Redis里的key是否真的存在。用redis-cli keys查一下如果key死活查不到检查是不是key前缀写错了。这四项排查下来基本能覆盖90%的防抖失效问题。5.2 AOP切面失效的典型原因AOP失效是SpringBoot开发里很经典的问题尤其在防抖这种场景下特别让人头疼。下面几个原因是我遇到次数最多的注解加在了Controller方法上但没有开启Spring AOP的代理支持。SpringBoot默认是开启了EnableAspectJAutoProxy的但如果你手动配置了代理方式可能会踩坑。类内部方法调用不走代理。比如A方法调用了同一个类里的B方法B方法上有NoRepeatSubmit注解这个注解不会生效因为代理对象只对A方法的调用进行了拦截B方法是直接调用目标对象的方法。注解加在了private方法上。Spring AOP基于动态代理private方法根本无法被代理注解直接无效。多数据源或自定义事务管理器导致代理模式改变。这种情况比较少见但如果你的项目里有复杂的事务配置可能是代理模式变了。排查AOP问题最有效的工具是打断点但如果启动时就想确认切面是否加载可以加一行启动日志在切面类的PostConstruct里打印一句“Aspect loaded”启动时看一眼日志就知道了。5.3 性能问题与调优建议很多人担心加了防抖之后会影响接口性能。实际上一次Redis交互耗时在1毫秒左右占整个接口耗时的比重非常低正常情况下不需要特别担心。但如果你的接口QPS非常高比如每秒几千次那就需要注意Redis的并发连接数和网络带宽。我个人实测的经验是单实例Redis在普通云服务器上QPS可以达到5万以上对接口防抖这种轻量操作完全不是瓶颈。真正的瓶颈在于业务本身就慢或者参数序列化耗时太长。如果确实对性能有极致要求可以考虑把请求指纹的MD5计算提前到网关层完成让网关把计算好的指纹塞到请求头里后端AOP直接取用。这样能省掉每次请求重复计算参数摘要的开销。另外如果你的项目里很多接口都需要防抖建议把公共逻辑抽成一个独立的starter模块注解和切面都放在里面不同服务直接引用避免到处复制粘贴。这样即使将来要调整防抖策略也只需要改一个地方。5.4 防抖与分布式锁怎么选最后再说一个很多人纠结的问题防抖和分布式锁到底什么关系能不能互相替代。防抖的核心词是“窗口期”。它关注的是在某个时间窗口内同样请求只允许处理一次。它不需要保证并发下的互斥性只需要保证“第二次来的时候第一次还没结束就拒绝它”。窗口期过后请求可以再次提交。分布式锁的核心词是“互斥”。它关注的是同一时刻只能有一个线程执行某段代码。它不管窗口期只处理并发。锁释放后下一个请求就能拿到锁继续执行。这就意味着如果两个重复请求同时到达防抖只能识别出其中一个另一个会被拒掉。但如果两个请求错开到达第一个已经处理完了第二个才到那防抖会放行第二个请求这也是合理的。如果你的需求是“同一业务在窗口期内只允许成功一次哪怕第二次是在第一次完成之后也要拒绝”那就要用防抖。如果你的需求是“同一时刻只能有一个请求处理但处理完之后允许下一个请求继续”那就要用分布式锁。大多数业务场景其实是防抖和幂等的组合接口层有防抖拦截业务层有幂等兜底双重保障。单纯靠防抖解决不了数据一致性问题单纯靠幂等也扛不住恶意刷接口。我个人在实际项目中的体会是防抖和幂等不是二选一的关系而是分层配合的关系。接口入口做防抖是给用户一个友好反馈业务逻辑做幂等是给数据一致性兜底。两者的成本其实都不高一个注解加一个切面的工作量换来的是线上少一大半重复数据投诉这笔账怎么算都划算。如果你正在设计新接口建议先把业务里天然的唯一键找出来比如订单号、请求流水号然后围绕这个唯一键同时做防抖和幂等。这个思路可以说是我做后端这几年收获最大的经验之一。