JEECG-Boot 接口幂等性实战指南如何防重复提交【免费下载链接】jeecg-boot【低代码v2.0一句话即可生成整个系统】企业级AI低代码平台一键生成前后端代码甚至整个系统。 AI Skills 一句话画流程、设计表单、生成报表、大屏。内置 AI应用平台涵盖AI聊天、知识库、流程编排、MCP插件等兼容主流大模型。引领AI低代码「Skills 生成 → 在线配置 → 代码生成 → 手工合并-AI修改」开发模式解决 Java 项目 90% 重复工作提高效率又不失灵活。项目地址: https://gitcode.com/GitHub_Trending/je/jeecg-boot用户连点两次提交系统里就多出一条订单、多扣一次款——接口不幂等是业务系统里最常见的线上事故来源之一。JEECG-Boot 这套企业级低代码平台里恰好有两样现成的工具一套基于 JWT 的 Token 校验链路一个基于 Redisson 的分布式锁。这篇文章结合仓库里真实的模块代码讲清楚怎么把这两样东西用起来落地 JEECG-Boot 接口幂等性以及上线前该防住哪些坑。先把两个词说透。接口幂等性大白话就是同一个请求打进来一次和打进来十次对系统的影响是一样的。而分布式锁就是多台机器抢一把钥匙同一时刻只有一台能进业务代码块别的都得等。这两件事解决的是同一个问题但站的位置不一样。先分清 Token 和分布式锁的适用边界一张表说清楚谁管什么维度Token 机制一次性票据Redisson 分布式锁守在哪请求入口挡在业务逻辑之前业务逻辑内部跨实例互斥挡的是什么用户双击、页面重试、前端重复提交多个实例、多个线程同时改同一份数据典型场景订单提交、表单保存、扣款发起秒杀扣库存、余额变更、定时任务互斥引入成本低Redis 里存取一个值就行高要管 key 设计、等待时间、过期时间何时组合用可能重复提交 服务多实例部署时Token 挡掉大头锁兜底说白了Token 是门票锁是单行道。只发门票不修单行道网络重试照样能把两个请求放进同一时刻只修单行道不发门票用户连点五次后四次全在锁外面傻等。三步把 JEECG-Boot 接口幂等性跑起来接入引一个依赖就够后端加jeecg-boot-starter-lock这一个依赖版本由根工程统一管理见 jeecg-boot/pom.xml。仓库里 jeecg-cloud-test-more 测试模块已经接好了照着抄不会错。配置把 Redisson 指对地方微服务版在 Nacos 的配置文件里配置jeecg-dev.yaml 里就有现成写法jeecg: redisson: address: jeecg-boot-redis:6379 password: type: STANDALONE enabled: trueaddress 换成你实际的 Redis 地址集群模式就把 type 改成 CLUSTER。业务代码里怎么用两种姿势注解方式最省事在方法上挂一个JLockkey 写死在常量里Scheduled(cron 0/5 * * * * ?) JLock(lockKey demo:lock:key1) public void execute() throws InterruptedException { // 业务逻辑 }编程方式更灵活tryLock拿到锁才执行拿不到直接走降级。完整的两种用法、包括获取失败怎么打日志都写在 DemoLockTest 里跑一遍比读十遍文档都清楚。Token 这边同理平台现成的是登录态那一套TokenUtils 负责校验 JWT、查 Redis 里的用户缓存、给 token 续期。做防重复提交时思路是同一套——提交前从 Redis 领一张一次性票据服务端校验通过后立刻删掉第二次提交票据已经没了直接拒绝。这几个坑不上线前真踩得到Token 有效期设太短用户干到一半被踢回登录页现象用户填了十分钟的表单一点提交提示token 已失效。原因校验链路里会顺带给 token 续期但前提是 Redis 里那条缓存还在基础有效期太短或者 Redis 被清过、换过节点缓存一丢在线用户集体掉线。解法有效期至少覆盖一张业务表单的最长填写时长上线前用 Redis 客户端搜一下 token 前缀的 key确认它真的写进去了别只看配置。锁持有时间给太肥别的请求全在排队现象某个慢接口跑完后面拿着同一个 key 的请求要等很久才能拿到锁。原因编程方式的tryLock有三个参数第二个是等锁的时长第三个是拿到锁之后最多持有多久。第三个值要是给得比业务实际耗时大几倍业务早就干完了锁还赖着只能干等它自己过期。解法持有时间按业务 P99 耗时的 1.5 到 2 倍给别图省事直接给几分钟。业务抛异常锁就挂在那了现象Redis 里锁的 key 迟迟不消失整条业务被堵死。原因unlock 写在业务代码后面而不是 finally 里异常一抛就跳过了释放。解法try-finally 包住业务unlock 永远放 finally拿不准就对着 DemoLockTest 里的编程式写法抄。锁 key 太粗不相关的业务互相卡脖子现象A 用户的订单在提交B 用户也被锁住了。原因key 写成了接口维度的order:save所有请求抢同一把锁。解法key 必须带上被操作资源的维度比如stock:sku:加 skuId让互斥只发生在真正会撞车的数据上。把两样东西放进一个系统里的判断标准门票守门、单行道守里这两件事不是二选一。日常表单类接口一次性 Token 挡重复提交基本够用一碰到多实例并发写同一份数据再把分布式锁补上key 对准具体资源。Token 的校验续期细节看 TokenUtils锁的两种用法对着 DemoLockTest 跑通幂等这块就不容易出事了 【免费下载链接】jeecg-boot【低代码v2.0一句话即可生成整个系统】企业级AI低代码平台一键生成前后端代码甚至整个系统。 AI Skills 一句话画流程、设计表单、生成报表、大屏。内置 AI应用平台涵盖AI聊天、知识库、流程编排、MCP插件等兼容主流大模型。引领AI低代码「Skills 生成 → 在线配置 → 代码生成 → 手工合并-AI修改」开发模式解决 Java 项目 90% 重复工作提高效率又不失灵活。项目地址: https://gitcode.com/GitHub_Trending/je/jeecg-boot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 JEECG-Boot 接口幂等性实战指南：如何防重复提交
JEECG-Boot 接口幂等性实战指南如何防重复提交【免费下载链接】jeecg-boot【低代码v2.0一句话即可生成整个系统】企业级AI低代码平台一键生成前后端代码甚至整个系统。 AI Skills 一句话画流程、设计表单、生成报表、大屏。内置 AI应用平台涵盖AI聊天、知识库、流程编排、MCP插件等兼容主流大模型。引领AI低代码「Skills 生成 → 在线配置 → 代码生成 → 手工合并-AI修改」开发模式解决 Java 项目 90% 重复工作提高效率又不失灵活。项目地址: https://gitcode.com/GitHub_Trending/je/jeecg-boot用户连点两次提交系统里就多出一条订单、多扣一次款——接口不幂等是业务系统里最常见的线上事故来源之一。JEECG-Boot 这套企业级低代码平台里恰好有两样现成的工具一套基于 JWT 的 Token 校验链路一个基于 Redisson 的分布式锁。这篇文章结合仓库里真实的模块代码讲清楚怎么把这两样东西用起来落地 JEECG-Boot 接口幂等性以及上线前该防住哪些坑。先把两个词说透。接口幂等性大白话就是同一个请求打进来一次和打进来十次对系统的影响是一样的。而分布式锁就是多台机器抢一把钥匙同一时刻只有一台能进业务代码块别的都得等。这两件事解决的是同一个问题但站的位置不一样。先分清 Token 和分布式锁的适用边界一张表说清楚谁管什么维度Token 机制一次性票据Redisson 分布式锁守在哪请求入口挡在业务逻辑之前业务逻辑内部跨实例互斥挡的是什么用户双击、页面重试、前端重复提交多个实例、多个线程同时改同一份数据典型场景订单提交、表单保存、扣款发起秒杀扣库存、余额变更、定时任务互斥引入成本低Redis 里存取一个值就行高要管 key 设计、等待时间、过期时间何时组合用可能重复提交 服务多实例部署时Token 挡掉大头锁兜底说白了Token 是门票锁是单行道。只发门票不修单行道网络重试照样能把两个请求放进同一时刻只修单行道不发门票用户连点五次后四次全在锁外面傻等。三步把 JEECG-Boot 接口幂等性跑起来接入引一个依赖就够后端加jeecg-boot-starter-lock这一个依赖版本由根工程统一管理见 jeecg-boot/pom.xml。仓库里 jeecg-cloud-test-more 测试模块已经接好了照着抄不会错。配置把 Redisson 指对地方微服务版在 Nacos 的配置文件里配置jeecg-dev.yaml 里就有现成写法jeecg: redisson: address: jeecg-boot-redis:6379 password: type: STANDALONE enabled: trueaddress 换成你实际的 Redis 地址集群模式就把 type 改成 CLUSTER。业务代码里怎么用两种姿势注解方式最省事在方法上挂一个JLockkey 写死在常量里Scheduled(cron 0/5 * * * * ?) JLock(lockKey demo:lock:key1) public void execute() throws InterruptedException { // 业务逻辑 }编程方式更灵活tryLock拿到锁才执行拿不到直接走降级。完整的两种用法、包括获取失败怎么打日志都写在 DemoLockTest 里跑一遍比读十遍文档都清楚。Token 这边同理平台现成的是登录态那一套TokenUtils 负责校验 JWT、查 Redis 里的用户缓存、给 token 续期。做防重复提交时思路是同一套——提交前从 Redis 领一张一次性票据服务端校验通过后立刻删掉第二次提交票据已经没了直接拒绝。这几个坑不上线前真踩得到Token 有效期设太短用户干到一半被踢回登录页现象用户填了十分钟的表单一点提交提示token 已失效。原因校验链路里会顺带给 token 续期但前提是 Redis 里那条缓存还在基础有效期太短或者 Redis 被清过、换过节点缓存一丢在线用户集体掉线。解法有效期至少覆盖一张业务表单的最长填写时长上线前用 Redis 客户端搜一下 token 前缀的 key确认它真的写进去了别只看配置。锁持有时间给太肥别的请求全在排队现象某个慢接口跑完后面拿着同一个 key 的请求要等很久才能拿到锁。原因编程方式的tryLock有三个参数第二个是等锁的时长第三个是拿到锁之后最多持有多久。第三个值要是给得比业务实际耗时大几倍业务早就干完了锁还赖着只能干等它自己过期。解法持有时间按业务 P99 耗时的 1.5 到 2 倍给别图省事直接给几分钟。业务抛异常锁就挂在那了现象Redis 里锁的 key 迟迟不消失整条业务被堵死。原因unlock 写在业务代码后面而不是 finally 里异常一抛就跳过了释放。解法try-finally 包住业务unlock 永远放 finally拿不准就对着 DemoLockTest 里的编程式写法抄。锁 key 太粗不相关的业务互相卡脖子现象A 用户的订单在提交B 用户也被锁住了。原因key 写成了接口维度的order:save所有请求抢同一把锁。解法key 必须带上被操作资源的维度比如stock:sku:加 skuId让互斥只发生在真正会撞车的数据上。把两样东西放进一个系统里的判断标准门票守门、单行道守里这两件事不是二选一。日常表单类接口一次性 Token 挡重复提交基本够用一碰到多实例并发写同一份数据再把分布式锁补上key 对准具体资源。Token 的校验续期细节看 TokenUtils锁的两种用法对着 DemoLockTest 跑通幂等这块就不容易出事了 【免费下载链接】jeecg-boot【低代码v2.0一句话即可生成整个系统】企业级AI低代码平台一键生成前后端代码甚至整个系统。 AI Skills 一句话画流程、设计表单、生成报表、大屏。内置 AI应用平台涵盖AI聊天、知识库、流程编排、MCP插件等兼容主流大模型。引领AI低代码「Skills 生成 → 在线配置 → 代码生成 → 手工合并-AI修改」开发模式解决 Java 项目 90% 重复工作提高效率又不失灵活。项目地址: https://gitcode.com/GitHub_Trending/je/jeecg-boot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考