在java中防止重复请求的核心方法是实现接口的幂等性，主要通过“幂等性令牌”或“唯一请求id”结合服务器端存储（如redis）来管理请求状态。具体步骤如下：1. 客户端在发起可能导致重复提交的操作前获取令牌；2. 服务器生成唯一令牌并存储至redis，设置过期时间；3. 客户端提交业务请求时携带该令牌；4. 服务器校验令牌有效性，若有效则执行业务逻辑并标记令牌为已使用，否则返回错误。此外，还可采用其他策略：5. 唯一请求id由客户端生成，适用于移动app或服务间调用；6. 数据库唯一约束用于防止数据层面的重复，如订单号重复；7. 乐观锁用于处理并发更新问题，确保数据一致性；8. 分布式锁用于高并发场景下的严格并发控制。每种策略各有适用场景与优缺点，常结合使用以增强可靠性。
在Java中防止重复请求，核心在于实现接口的幂等性。这通常通过在服务器端维护一个请求状态或唯一标识符来实现，确保同一个逻辑操作无论被执行多少次，其结果都是一致的，并且不会产生副作用。
实现Java接口的去重机制，最常见且有效的方式是采用“幂等性令牌”（Idempotent Token）或“唯一请求ID”（Unique Request ID）结合服务器端存储（如Redis）来管理请求的状态。
具体而言，当客户端发起一个可能导致重复提交的操作（例如表单提交、支付请求、创建订单等），在实际业务逻辑执行前，我们会进行一次预检。这个预检会验证当前请求是否已经处理过，或者是否携带了一个有效的、尚未使用的令牌。如果验证通过，则继续执行业务逻辑，并同时标记该请求或令牌为已使用；如果验证失败，则直接返回错误或已处理状态，从而阻止重复操作的发生。这种机制的关键在于，服务器端需要能够快速、可靠地存储和查询这些请求标识符或令牌的状态。
立即学习“Java免费学习笔记（深入）”；
说实话，开发中遇到重复请求真是个让人头疼的问题。它不像一个bug，代码逻辑可能完全正确，但就是因为外部环境或者用户的一些“无意”操作，导致同一个请求被发送了多次。这背后的原因其实挺多的，比如：
网络波动：最常见的，请求发出去后，客户端没收到服务器的响应（可能网络延迟或丢包），于是它觉得“没成功”，就又重发了一次。 用户行为：用户手抖点两下提交按钮，或者提交后觉得慢，又刷新了一下页面，浏览器可能就把上次的POST请求又发了一遍。 客户端重试机制：有些前端框架或者SDK自带重试逻辑，在收到非200状态码时会自动重试，这在处理超时或者瞬时错误时有用，但也可能导致重复。 分布式系统中的异步处理：在微服务架构里，一个操作可能涉及到多个服务的调用，如果中间某个环节失败需要补偿或重试，也可能间接导致上游请求的“重复”效果。
这些场景下，如果不做处理，轻则数据重复（比如创建了两条一样的订单），重则资损（比如支付了两次）。所以，这不是一个简单的UI层面的问题，而是需要深入到服务层去考虑接口的“幂等性”。所谓幂等，就是说一个操作，无论执行一次还是多次，最终结果都是一样的，不会对系统状态产生额外的影响。这听起来简单，但实现起来可不轻松，尤其是在高并发和分布式环境下，要保证状态的一致性和原子性，挑战真的不小。
幂等性令牌机制，我个人觉得是处理重复请求非常优雅且普遍适用的方案。它的核心思想是：每次可能发生重复提交的请求，都必须携带一个由服务器预先发放的、一次性的“通行证”。
流程大概是这样：
X-Idempotent-Token）或者请求参数中一并发送给服务器。代码实现上的一些考量：
我们通常会用Spring AOP或者Interceptor来实现这个令牌的校验逻辑，这样可以将业务代码和去重逻辑解耦。
// 假设有一个自定义注解用于标记需要幂等处理的接口
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Idempotent {
String value() default ""; // 可选，用于区分不同业务的幂等
}
// 令牌服务接口
public interface TokenService {
String generateToken();
boolean checkToken(String token);
void deleteToken(String token); // 或者标记为已使用
}
// TokenService 的 Redis 实现
@Service
public class RedisTokenService implements TokenService {
@Autowired
private StringRedisTemplate redisTemplate;
private static final String IDEMPOTENT_TOKEN_PREFIX = "idempotent:token:";
private static final long TOKEN_EXPIRE_TIME = 30 * 60; // 30分钟
@Override
public String generateToken() {
String token = UUID.randomUUID().toString();
// 使用SETNX，确保只有第一次设置成功，防止并发生成相同token
redisTemplate.opsForValue().setIfAbsent(IDEMPOTENT_TOKEN_PREFIX + token, "1", TOKEN_EXPIRE_TIME, TimeUnit.SECONDS);
return token;
}
@Override
public boolean checkToken(String token) {
if (StringUtils.isEmpty(token)) {
return false;
}
// 使用 delete() 方法，如果删除成功，说明是第一次使用，并原子性地消耗了令牌
Boolean deleted = redisTemplate.delete(IDEMPOTENT_TOKEN_PREFIX + token);
return Boolean.TRUE.equals(deleted);
}
@Override
public void deleteToken(String token) {
redisTemplate.delete(IDEMPOTENT_TOKEN_PREFIX + token);
}
}
// 幂等性拦截器或AOP切面
@Component
public class IdempotentInterceptor implements HandlerInterceptor {
@Autowired
private TokenService tokenService;
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
if (handler instanceof HandlerMethod) {
HandlerMethod handlerMethod = (HandlerMethod) handler;
Idempotent idempotent = handlerMethod.getMethodAnnotation(Idempotent.class);
if (idempotent != null) {
String token = request.getHeader("X-Idempotent-Token"); // 从请求头获取令牌
if (StringUtils.isEmpty(token)) {
// 没有令牌，可能是非法请求或未按约定流程
response.setStatus(HttpStatus.BAD_REQUEST.value());
response.getWriter().write("Missing idempotent token.");
return false;
}
if (!tokenService.checkToken(token)) {
// 令牌无效或已使用，视为重复请求
response.setStatus(HttpStatus.CONFLICT.value()); // 409 Conflict
response.getWriter().write("Duplicate request or invalid token.");
return false;
}
}
}
return true; // 继续处理请求
}
}
// 在WebMvcConfigurer中注册拦截器
@Configuration
public class WebConfig implements WebMvcConfigurer {
@Autowired
private IdempotentInterceptor idempotentInterceptor;
@Override
public void addInterceptors(InterceptorRegistry registry) {
registry.addInterceptor(idempotentInterceptor)
.addPathPatterns("/**"); // 拦截所有请求，在拦截器内部判断是否需要幂等处理
}
}
// 在Controller中使用
@RestController
@RequestMapping("/api/orders")
public class OrderController {
@PostMapping("/create")
@Idempotent
public ResponseEntity<String> createOrder(@RequestBody OrderDTO orderDTO) {
// 业务逻辑处理
System.out.println("Processing order: " + orderDTO.getOrderNo());
return ResponseEntity.ok("Order created successfully.");
}
@GetMapping("/token")
public ResponseEntity<String> getToken() {
return ResponseEntity.ok(tokenService.generateToken());
}
}这种方案的优势在于，它将幂等性逻辑从业务代码中剥离出来，通过拦截器实现了横向切入。令牌的生成和校验都依赖于Redis的原子操作，在高并发下也能保证正确性。当然，令牌的过期时间需要根据实际业务场景来设定，太短可能导致用户还没来得及提交就失效，太长则可能占用过多资源。
幂等性令牌确实好用，但它也不是唯一的解决方案，或者说，有些场景下，我们会有更“自然”或者更贴合业务的去重方式。
1. 唯一请求ID（Client-generated UUID）
这跟令牌机制有点像，但区别在于，唯一ID是由客户端自己生成的，而不是服务器预先发放。
X-Request-ID）或请求参数的一部分发送。服务器接收到请求后，将这个ID存储到Redis（同样设置TTL），并检查这个ID是否已经存在。如果不存在，则处理请求并存储ID；如果存在，则认为是重复请求。2. 数据库唯一约束
对于某些特定业务，直接利用数据库的唯一约束是最高效且最可靠的去重方式。
3. 乐观锁
乐观锁主要用于解决并发更新问题，但在某种程度上，也可以防止“重复更新”。
4. 分布式锁
在某些非常关键的业务场景，比如支付的核心处理流程，可以考虑使用分布式锁。
总的来说，选择哪种去重策略，真的要看具体的业务场景和对可靠性的要求。令牌机制和唯一请求ID是比较通用的接口去重方案，而数据库唯一约束和乐观锁更多是针对数据层面的完整性保障。分布式锁则是在极端高并发和高一致性要求下的“重武器”。很多时候，这些策略并不是互斥的，而是可以组合使用的，比如在接口层面用令牌去重，在数据层面再加个唯一约束，这样就更稳妥了。
以上就是如何在Java中实现防止重复请求 Java接口去重机制逻辑示例的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
657
收藏
