Java后端防重提交实战：从幂等性原理到Redis Token方案详解

防重提交幂等性Redis Token

于 2026-08-04 04:01:53 修改

·本内容遵循CC 4.0 BY-SA版权协议

1. 防重提交到底在解决什么线上问题？

如果你在面试或者实际工作中被问到“防重提交”，别急着背“幂等性”的定义。先想一个最直接的场景：一个用户在前端疯狂点击“提交订单”按钮，或者因为网络延迟重复发送了请求，你的后端服务会怎么处理？

是创建了多个一模一样的订单，导致用户重复支付？还是扣减了多次库存，把商家的货给卖超了？又或者，在分布式环境下，多个服务实例同时收到了同一个请求，它们之间如何协调，确保只处理一次？

防重提交要解决的，就是这类由“重复请求”引发的业务数据错乱和资损风险。 它不是一个炫技的八股文考点，而是一个直接影响系统稳定性和钱包的工程实践。对于Java后端开发来说，无论是面试还是实际开发，这都是必须掌握的核心场景。理解它，关键不在于记住几种实现方案的名字，而在于搞清楚每种方案的适用场景、边界和可能踩的坑。

很多人学不会，是因为一开始就陷入了“Redis分布式锁”、“Token机制”、“数据库唯一索引”这些具体技术的细节里，却没想明白：我的业务场景里，重复请求到底是怎么产生的？允许的重复时间窗口是多久？为了防重，我愿意付出多少性能代价和复杂度？

这篇文章，我们就从一个线上可能真实发生的“重复订单”问题出发，拆解防重提交的设计思路、常见实现方案，以及更重要的——在面试和实战中，你应该如何分析和回答这类问题。

2. 从一次“幽灵订单”事故看问题本质

假设你维护着一个电商系统。某天，客服突然反馈有用户投诉，说自己只点了一次付款，却生成了两个订单，扣了两次钱。查看日志，你会发现类似这样的痕迹：

TEXT

// 请求1

[14:30:01.123] INFO - 用户UID:1001 请求创建订单，订单号预生成: ORDER_20240415143001123

[14:30:01.456] INFO - 订单ORDER_20240415143001123 扣减库存成功。

[14:30:01.789] INFO - 订单ORDER_20240415143001123 支付回调成功，订单状态更新为“已支付”。

// 请求2 (几乎同时发生)

[14:30:01.124] INFO - 用户UID:1001 请求创建订单，订单号预生成: ORDER_20240415143001124

[14:30:01.460] INFO - 订单ORDER_20240415143001124 扣减库存成功。

[14:30:01.795] INFO - 订单ORDER_20240415143001124 支付回调成功，订单状态更新为“已支付”。

两个请求的时间戳相差仅1毫秒，用户ID、商品信息完全一致，但生成了两个独立的订单号，流程都走完了。这就是最典型的“重复提交”线上问题。

为什么会出现这种情况？

前端防重失效：按钮可能没有做点击防抖（Debounce）或加载状态锁定，用户快速双击。
网络问题：用户点击后，前端请求发出，因网络延迟未及时收到响应，用户以为失败又点了一次。
后端处理超时：第一次请求后端已处理，但因某些操作（如调用外部支付网关）耗时较长，在返回结果前，前端超时重试了。
分布式环境并发：在微服务架构下，请求可能被负载均衡到不同的服务实例，这两个实例几乎同时处理了“相同的”请求。

前端防重属于用户体验优化，不能作为安全保证。后端防重才是最后且必须的防线。 我们的目标就是：对于同一笔业务意图的请求，无论来多少次，最终只有一次生效。

3. 防重提交的核心设计思路与方案选型

防重的本质是实现幂等性。幂等性意味着一个操作执行一次与执行多次的效果相同。设计防重方案时，你需要一个幂等键来标识同一笔业务。这个键的选择至关重要，它需要满足：

唯一性：能唯一标识一笔业务请求。
一致性：在请求的重复发送过程中，这个键保持不变。
可获取性：在业务逻辑执行前或执行中能够拿到。

常见的幂等键有：前端生成的唯一Token、订单号、业务流水号、用户ID+业务类型+关键参数组合的MD5值等。

下面我们分析几种主流的后端防重方案，重点不是罗列代码，而是理解其原理和适用边界。

3.1 方案一：数据库唯一索引/主键冲突

这是最直接、依赖最少的方法。

如何做： 在数据库表中，为幂等键字段建立唯一索引。当插入业务记录（如订单）时，将幂等键作为唯一约束字段插入。第一次插入成功，第二次插入时会因唯一索引冲突而失败。

示例场景： 使用数据库生成的订单号或请求时生成的唯一流水号作为幂等键。

SQL

CREATE TABLE `order` (

`id` bigint NOT NULL AUTO_INCREMENT,

`order_sn` varchar(64) NOT NULL COMMENT '订单号，幂等键',

`user_id` bigint NOT NULL,

-- ... 其他字段

PRIMARY KEY (`id`),

UNIQUE KEY `uk_order_sn` (`order_sn`) -- 唯一索引

) ENGINE=InnoDB;

JAVA

// 伪代码示例

public boolean createOrder(CreateOrderRequest request) {

// 1. 生成或获取幂等键 (例如，订单号orderSn)

String idempotentKey = generateOrderSn(request);

// 2. 尝试插入订单，以订单号为唯一约束

try {

orderDao.insertOrder(idempotentKey, request.getUserId(), ...);

// 3. 插入成功，继续后续扣库存、创建支付单等业务逻辑

reduceStock(request);

createPayment(orderId);

return true;

} catch (DuplicateKeyException e) {

// 4. 捕获唯一键冲突异常，说明是重复请求

log.warn("重复订单请求，幂等键: {}", idempotentKey);

// 可选：查询已存在的订单并返回

Order existingOrder = orderDao.selectByOrderSn(idempotentKey);

return true; // 或返回特定结果，告知请求已处理

}

优点：

简单可靠：利用数据库自身能力，强一致。
无需额外中间件：适合简单系统或作为辅助手段。

缺点与边界：

数据库压力：所有重复请求都会走到数据库，并触发索引冲突检查，高并发下对数据库是压力。
业务逻辑耦合：防重判断与业务数据插入绑定，如果业务创建流程复杂（需要调用多个外部服务），在插入订单后、完成全部流程前发生失败，可能会留下一个“半成品”订单记录。此时重试请求会因为唯一键冲突而无法继续，需要额外的状态机或补偿机制来处理。
仅适用于创建场景：对于更新操作（如扣减库存），单纯唯一索引不够。

面试点睛： 当面试官问到这个方案时，你一定要提到DuplicateKeyException和数据库压力这个点，并说明它更适合并发不高、业务逻辑相对简单的创建场景。

3.2 方案二：Redis Token 机制（或类似分布式缓存）

这是面试中最常被提及的方案，核心思想是“一次兑换”。

如何做：

在请求业务接口前，先调用一个“获取Token”的接口。服务端生成一个全局唯一的Token（如UUID），存入Redis，并设置一个合理的过期时间（如5分钟），然后将Token返回给客户端。
客户端请求业务接口时，携带此Token（通常放在Header或Param中）。
服务端收到业务请求后：
- 从Redis中尝试删除这个Token（使用DEL命令或GET+DEL的Lua脚本保证原子性）。
- 如果删除成功（返回1），说明是第一次请求，执行业务逻辑。
- 如果删除失败（返回0），说明Token不存在（已使用过或已过期），判定为重复请求，直接返回之前的处理结果。

JAVA

// 伪代码示例 - 业务接口处理

public ApiResponse processBusiness(BusinessRequest request, HttpHeaders headers) {

String token = headers.getFirst("X-Idempotent-Token");

if (StringUtils.isEmpty(token)) {

return ApiResponse.fail("缺少幂等Token");

}

// 使用Lua脚本或Redis的 `SET key value NX EX` + `DEL` 组合来保证原子性判断

// 这里以简单示意为例，生产环境建议用Lua脚本

String redisKey = "idempotent:token:" + token;

// 原子性删除并返回删除数量

Long result = redisTemplate.delete(redisKey);

// 也可以用 `setIfAbsent` 占位，这里用删除更直观

if (result != null && result == 1L) {

// 第一次请求

// 1. 执行核心业务逻辑...

Object businessResult = doRealBusiness(request);

// 2. 可以将本次请求的结果存入Redis，Key可以用业务ID或Token，设置较长过期时间，供重复请求时直接返回

cacheResult(redisKey, businessResult);

return ApiResponse.success(businessResult);

} else {

// 重复请求

log.info("检测到重复请求，Token: {}", token);

// 尝试从缓存中获取上一次的处理结果

Object cachedResult = getCachedResult(redisKey);

return ApiResponse.success(cachedResult != null ? cachedResult : "请求已处理");

}

优点：

性能好：判断逻辑在内存中完成，速度快，减轻数据库压力。
解耦业务：防重判断在业务逻辑之前，业务逻辑本身无需关心是否重复。
适用于各类操作：创建、更新、删除等操作均可使用。

缺点与边界：

额外网络开销：需要引入并维护Redis。
原子性与并发问题：GET和DEL非原子操作，在极高并发下可能两个请求都读到Token并都去删除，导致都执行业务。必须使用Lua脚本或Redis的原子命令（如SETNX配合DEL） 来保证“判断-删除”的原子性。
结果缓存：对于重复请求，需要能够返回相同的结果。这就要求第一次处理成功后，需要把结果缓存起来（缓存时间需长于Token过期时间），增加了复杂度。
Redis可用性：Redis挂掉会导致防重失效，需要降级策略（如降级为数据库防重或记录日志告警）。

面试点睛： 这是高频考点。你必须能说清楚 “获取Token -> 携带Token请求 -> 原子性校验Token” 的完整流程，并重点强调原子性问题和结果缓存的考虑。面试官可能会追问：“如果两个请求同时到达，如何保证只有一个能拿到Token并执行业务？” 答案就是Lua脚本或分布式锁。

3.3 方案三：数据库悲观锁/乐观锁

这类方案更侧重于在更新场景下防止数据被重复更新，实现最终一致性。

悲观锁（SELECT ... FOR UPDATE）：在事务中，先通过SELECT FOR UPDATE锁定涉及的业务数据行（如库存记录）。在锁持有期间，其他相同请求会被阻塞，从而串行化处理。性能差，容易死锁，不推荐在高并发场景下作为防重首选。
乐观锁：在数据表中增加一个版本号字段（version）。更新时，带上读取时的版本号。更新语句的WHERE条件中同时指定主键和版本号。如果版本号已变更（说明数据被其他请求修改过），则更新影响行数为0，可判定为重复或冲突请求。

SQL

-- 乐观锁示例

UPDATE product_stock

SET stock = stock - 1,

version = version + 1

WHERE product_id = 100 AND version = 1;

-- 执行后检查 affected_rows，如果为0，说明更新失败（版本不对或库存不足）

优点：

乐观锁并发度高：无锁设计，适合读多写少。
精准控制数据更新：直接防止数据错乱。

缺点与边界：

业务侵入性强：需要在数据表和业务逻辑中增加版本控制。
失败处理：乐观锁更新失败后，业务上需要决定是重试、抛错还是返回特定信息。
范围有限：主要解决数据更新层面的并发，对于完整的业务流程防重（如创建订单涉及多张表、多个外部调用），需要与其他方案结合。

面试点睛： 区分悲观锁和乐观锁的适用场景。对于防重提交，更常讨论的是乐观锁如何避免重复更新。要能写出乐观锁的SQL示例，并说明如何根据affected_rows判断结果。

3.4 方案四：分布式锁（Redis Redisson等）

在分布式环境下，如果需要确保一段业务逻辑（不仅仅是数据插入）全局只执行一次，可以使用分布式锁。

如何做： 以Redisson为例，在业务逻辑开始前，尝试获取一个以幂等键为标识的分布式锁。获取成功则执行业务，执行完毕后释放锁；获取失败（锁已被其他请求持有）则等待或直接返回。

JAVA

// 伪代码示例

public ApiResponse processWithDistributedLock(BusinessRequest request) {

String lockKey = "idempotent:lock:" + generateIdempotentKey(request);

RLock lock = redissonClient.getLock(lockKey);

// 尝试加锁，最多等待100ms，锁持有时间10秒

boolean isLocked = false;

try {

isLocked = lock.tryLock(100, 10000, TimeUnit.MILLISECONDS);

if (!isLocked) {

// 获取锁失败，可认为是重复请求正在处理中

return ApiResponse.fail("系统正在处理中，请勿重复提交");

}

// 获取锁成功，执行核心业务逻辑

return doBusinessAndCacheResult(request, lockKey);

} catch (InterruptedException e) {

Thread.currentThread().interrupt();

return ApiResponse.fail("系统繁忙");

} finally {

if (isLocked && lock.isHeldByCurrentThread()) {

lock.unlock();

}

优点：

强一致性保证：可以保护一个临界区代码块只执行一次。
灵活性：锁的粒度可以控制（业务全局、用户级别等）。

缺点与边界：

性能开销：加锁解锁有开销，且如果锁持有时间过长，会影响系统吞吐。
复杂度：需要处理锁超时、锁续期、锁释放异常等问题，Redisson等客户端帮我们解决了很多，但仍需小心使用。
杀鸡用牛刀：对于简单的防重提交（如插入防重），用分布式锁显得过重。它更适合于防止分布式环境下，多个节点同时执行某个定时任务、数据初始化等复杂操作的场景。

面试点睛： 明确分布式锁和防重提交的关系。防重提交是目标，分布式锁是实现手段之一，但通常不是最优选。要向面试官说明，单纯的防重提交，优先考虑Token机制；如果需要保护一个复杂的、非幂等的业务流程片段，才考虑分布式锁。

4. 面试与实战：如何系统性地回答和设计？

当面试官抛出“如何设计防重提交？”时，不要只扔出一个技术名词。按照以下结构回答，会显得你思考全面，有实战经验。

4.1 分析业务场景与需求

首先，澄清问题背景：

“请问这个防重主要是针对哪种操作？是创建订单、支付回调、还是库存扣减？”
“预期的重复时间窗口是多久？是秒级重复点击，还是分钟级网络超时重试？”
“业务上对一致性的要求有多高？是强一致还是最终一致可接受？”
“系统的并发量大概是什么级别？”

4.2 阐述设计思路与方案选型

基于场景，给出你的方案：

幂等键设计：“我会选择一个合适的幂等键，比如前端生成UUID作为Token，或者用‘用户ID+商品ID+时间戳’的哈希值。”
方案选择与对比：
- “如果业务逻辑简单，主要是插入操作，且并发量不大，可以考虑用数据库唯一索引，实现简单，但要注意数据库压力。”
- “如果是通用场景，我倾向于使用Redis Token机制。它的性能好，与业务解耦。关键点是要用Lua脚本保证‘判断-删除’的原子性，并且要考虑好第一次请求结果的缓存，以便重复请求时能直接返回。”
- “如果是更新操作，比如扣库存，可以在数据层采用乐观锁，通过版本号控制。”
- “如果是要保证一个复杂的分布式任务只跑一次，可能会用到分布式锁，但对于普通API防重来说有点重。”
降级与容错：“任何依赖外部存储（如Redis、DB）的方案都要考虑可用性。如果Redis不可用，可以降级到本地缓存（如Guava Cache）加告警，或者暂时放宽防重策略，记录日志事后核对，核心是保证主流程不中断。”

4.3 给出一个完整的、可落地的示例

以最常用的Redis Token方案为例，描述一个完整流程：

TEXT

1. 【客户端】进入需要防重的页面时，调用服务端 `/api/token/generate` 接口。

2. 【服务端】生成UUID作为Token，以 `idempotent:token:{token}` 为Key，值为`1`（或预留的业务标识），设置过期时间（如300秒），存入Redis。将Token返回给客户端。

3. 【客户端】提交业务请求（如创建订单）时，在HTTP Header（如 `X-Idempotent-Token`）中携带此Token。

4. 【服务端】拦截器或AOP切面处理：

a. 检查Header中是否存在Token，无则报错。

b. 构造Redis Key。

c. **执行Lua脚本**：判断Key是否存在，若存在则删除并返回1，否则返回0。保证原子性。

d. 如果脚本返回1，说明是首次请求：

i. 执行业务逻辑。

ii. 业务执行成功，将结果序列化后，以 `idempotent:result:{token}` 为Key存入Redis，过期时间略长于Token（如600秒）。

iii. 返回业务结果。

e. 如果脚本返回0，说明是重复请求：

i. 尝试从 `idempotent:result:{token}` 中获取已缓存的结果。

ii. 如果获取到，直接返回该结果。

iii. 如果未获取到（可能结果未缓存或已过期），可返回“请求正在处理中”或“请勿重复提交”等通用提示。

5. 【客户端】收到响应，处理业务结果。

4.4 指出潜在问题与优化点

展示你的深度思考：

Token窃取与伪造：Token如果被恶意截获并伪造，会导致防重失效。可以通过HTTPS、对Token进行签名（JWT）、绑定用户会话等方式增强安全性。
流程中断与结果缓存：如果第一次请求在业务逻辑执行成功之后、结果缓存之前服务崩溃，会导致重复请求无法获取结果。可以考虑将结果缓存放在事务内或最后一步，并做好日志记录。
Redis集群与数据分片：在Redis集群下，要确保同一个Token的“判断-删除”和“结果存取”落在同一个节点上，可以使用相同的Key，Redis集群的哈希分片机制会保证这一点。
幂等键的粒度：防重粒度是全局、用户级还是会话级？根据业务决定。例如，防止用户重复领券，幂等键可以是用户ID+活动ID。

5. 总结：从知道到做到的几个关键点

防重提交不是一个可以死记硬背的“八股文”，而是一个需要根据业务场景灵活设计和组合的工程方案。从知道概念到能在线上稳定运行，你需要跨越几个关键点：

第一，区分“防重”与“幂等”。 防重是一种技术手段，目标是防止重复请求造成不良影响。幂等是接口的一种属性，是防重要达到的效果。设计时，我们追求的是让关键业务接口具备幂等性。

第二，没有银弹，只有权衡。 数据库唯一索引简单但性能有瓶颈；Redis方案性能好但引入了外部依赖和缓存一致性问题；分布式锁能力强大但复杂度高。你的选择取决于业务的并发量、数据一致性要求、团队技术栈和运维能力。

第三，实战比理论复杂。 理论方案只给了你骨架，血肉需要自己填充：Token如何生成和传递？原子性操作如何真正落地？服务降级怎么做？日志如何打，才能快速定位一个疑似重复请求的问题？这些都需要在项目中反复打磨。

最后，在面试中展现你的思考过程，远比背出一个标准答案更重要。 从问题场景出发，到方案选型，再到细节实现和风险考量，这条完整的逻辑链，才是面试官真正想考察的“线上问题分析”能力。下次遇到“防重提交”的问题，不妨就从“我们曾经遇到过一个重复订单的线上问题……”开始你的回答。