1. 重复提交问题的本质与危害在Web应用中重复提交是个老生常谈却又极易被忽视的问题。想象这样一个场景用户点击支付按钮后页面卡顿了几秒于是又连点了几次。结果后台处理了多条相同的支付请求导致用户被重复扣款。这就是典型的重复提交问题。从技术角度看重复提交主要发生在以下三种场景用户短时间内多次点击提交按钮网络延迟导致用户重复提交表单页面刷新或后退导致的重复提交在高并发环境下这个问题会被放大。假设一个秒杀系统如果不做防重处理1万个用户同时点击可能产生5万次请求。这不仅会造成数据错乱还会给数据库带来巨大压力。关键提示防重设计的核心不是阻止用户操作而是确保相同业务逻辑只被执行一次。这需要在前端和后端同时做控制。2. 技术选型为什么是注解切面Redis2.1 传统方案的局限性常见的防重方案各有优缺点方案实现方式优点缺点前端防抖JavaScript控制按钮点击间隔实现简单可被绕过不可靠Token机制生成唯一token随表单提交安全性较好需要维护token状态数据库唯一索引关键字段加唯一约束绝对可靠高并发下性能差2.2 注解切面Redis的优势我们的方案结合了三者的优势自定义注解声明式标记需要防重的方法切面编程统一处理防重逻辑与业务代码解耦Redis高性能存储防重标记支持分布式环境这种组合的独特价值在于开发效率只需添加注解即可实现防重性能Redis内存操作毫秒级响应可靠性分布式环境下依然有效灵活性可自定义防重时间窗口3. 核心实现详解3.1 自定义注解设计首先定义防重注解Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface NoRepeatSubmit { /** * 防重时间窗口秒 */ int lockTime() default 3; /** * 业务标识支持SpEL表达式 */ String key() default ; }关键设计点lockTime控制防重时间窗口默认3秒key支持SpEL表达式实现灵活的业务标识注解仅标记在方法级别保持简洁3.2 切面逻辑实现核心切面代码如下Aspect Component public class NoRepeatSubmitAspect { Autowired private RedisTemplateString, Object redisTemplate; Around(annotation(noRepeatSubmit)) public Object around(ProceedingJoinPoint pjp, NoRepeatSubmit noRepeatSubmit) throws Throwable { // 1. 构造Redis key String key buildKey(pjp, noRepeatSubmit); // 2. 尝试获取锁 Boolean success redisTemplate.opsForValue() .setIfAbsent(key, 1, noRepeatSubmit.lockTime(), TimeUnit.SECONDS); if (Boolean.FALSE.equals(success)) { throw new RuntimeException(请勿重复提交); } // 3. 执行业务逻辑 try { return pjp.proceed(); } finally { // 可根据业务需求决定是否立即删除key } } private String buildKey(ProceedingJoinPoint pjp, NoRepeatSubmit noRepeatSubmit) { // 实现key的构建逻辑 } }3.3 Redis键设计策略键的设计直接影响防重的精确度。推荐采用防重前缀:用户ID:方法名:参数摘要例如no_repeat:1001:orderService.submit:md5(param1value1param2value2)实现要点包含用户维度不同用户互不影响方法名确保不同接口独立防重参数摘要识别相同业务请求使用MD5压缩长参数4. 高级优化与实战技巧4.1 防重时间窗口的动态调整固定时间窗口可能不适合所有场景。我们可以改进注解NoRepeatSubmit( key #order.userId:#order.productId, lockTime #order.isVip ? 5 : 3 // VIP用户放宽限制 ) public void submitOrder(Order order) { // 业务逻辑 }通过SpEL实现根据业务属性动态调整时间窗口VIP用户可设置更长防重间隔关键操作可延长保护时间4.2 集群环境下的增强方案在分布式系统中还需要考虑Redis集群的高可用配置本地缓存与Redis的二级防重时钟同步问题NTP服务Redis持久化策略AOFRDB建议配置# Redis连接池配置 spring.redis.lettuce.pool.max-active20 spring.redis.lettuce.pool.max-wait200ms spring.redis.timeout1000ms4.3 性能压测数据使用JMeter测试对比单Redis节点8核16G方案QPS平均响应时间错误率无防重12,00015ms0%数据库唯一索引1,200150ms0.5%本方案9,80018ms0%关键发现相比数据库方案性能下降仅18%错误率保持为0可靠性有保障Redis成为瓶颈前可水平扩展5. 生产环境踩坑实录5.1 缓存穿透问题某次大促时发现Redis CPU飙高。经排查大量不同参数的请求导致防重key爆炸式增长每个key都要执行setIfAbsent操作解决方案对参数摘要进行抽样如只取前5个参数添加本地缓存过滤明显无效请求限制单个用户的防重key数量5.2 SpEL表达式性能陷阱初期实现中key的SpEL表达式解析耗时较长// 错误示范 - 每次请求都解析表达式 String key spelExpressionParser.parseExpression(annoKey).getValue(context, String.class);优化方案缓存解析后的Expression对象简单场景改用字符串拼接预编译常用表达式优化后性能提升40%。5.3 Redis连接池耗尽日志中频繁出现Could not get Redis connection异常。原因是防重切面未正确处理连接高并发下连接被占满修复方法try { return pjp.proceed(); } finally { RedisConnectionUtils.unbindConnection(redisTemplate.getConnectionFactory()); }6. 最佳实践建议粒度控制不要滥用防重只对关键业务方法添加注解监控报警对防重触发次数设置监控发现异常流量降级策略Redis不可用时可降级为本地缓存防重前端配合虽然后端防重是必须的但前端也应做基础防抖文档说明在接口文档中明确标注防重时间窗口典型配置示例NoRepeatSubmit( key #userId:#productId, // 用户商品维度防重 lockTime 5 // 电商下单场景建议5秒 ) public OrderResult submitOrder(Long userId, Long productId) { // 下单逻辑 }这套方案在我们多个核心系统中稳定运行日均拦截重复请求超过百万次。特别是在秒杀、支付等场景下既保证了系统稳定性又避免了数据错乱问题。
