彻底解决重复请求问题：Java幂等设计实战指南
项目地址: https://gitcode.com/GitHub_Trending/ja/java-design-patterns 你是否还在为重复提交、网络重试导致的数据错乱而头疼？支付系统重复扣款、订单状态异常、库存超卖——这些问题的根源往往指向同一个技术痛点：非幂等的接口设计。本文将通过3种实战方案+2个完整案例，带你构建从接口到架构的全链路幂等防护体系，读完你将掌握：
- 基于数据库的防重表实现方案
- 令牌桶+Redis的分布式幂等设计
- 状态机模式在订单流程中的应用
- 微服务场景下的幂等消费最佳实践
什么是幂等性？
幂等性（Idempotence） 是指任意多次执行同一操作所产生的影响均与一次执行的影响相同。在分布式系统中，由于网络延迟、服务重试、消息重投等场景，确保接口幂等性成为数据一致性的核心保障。
幂等性概念图示
官方实现参考：microservices-idempotent-consumer 模块提供了消息队列场景下的幂等处理完整示例
方案一：数据库防重表实现
实现原理
通过唯一索引约束确保重复请求无法插入重复记录，适用于订单创建、支付提交等核心场景。
@Entity
@Table(uniqueConstraints = {
@UniqueConstraint(columnNames = {"requestId", "businessType"})
})
public class IdempotentRecord {
@Id
private Long id;
private String requestId; // 全局唯一请求ID
private String businessType; // 业务类型
private LocalDateTime createTime;
}
关键代码
@Transactional
public void processOrder(String requestId, OrderDTO order) {
// 1. 尝试插入防重记录
IdempotentRecord record = new IdempotentRecord();
record.setRequestId(requestId);
record.setBusinessType("ORDER_CREATE");
try {
idempotentRecordRepository.save(record);
} catch (DataIntegrityViolationException e) {
log.warn("重复请求检测: requestId={}", requestId);
return;
}
// 2. 执行业务逻辑
orderService.createOrder(order);
}
完整实现见：RequestRepository.java
方案二：Redis分布式锁方案
架构设计
Redis幂等设计架构
代码实现
@Service
public class IdempotentService {
@Autowired
private StringRedisTemplate redisTemplate;
public <T> T executeWithIdempotence(String key, Supplier<T> action, long expireSeconds) {
// 1. 尝试获取锁
Boolean locked = redisTemplate.opsForValue().setIfAbsent(
"idempotent:" + key,
"LOCKED",
expireSeconds,
TimeUnit.SECONDS
);
if (Boolean.TRUE.equals(locked)) {
try {
return action.get(); // 执行核心业务
} finally {
redisTemplate.delete("idempotent:" + key); // 释放锁
}
} else {
throw new DuplicateRequestException("请求处理中，请稍后再试");
}
}
}
方案三：状态机模式
在订单、支付等有明确流程的业务中，通过状态机控制流转，防止重复操作：
public enum OrderStatus {
CREATED, PAID, SHIPPED, COMPLETED, CANCELLED;
// 状态流转矩阵
private static final Map<OrderStatus, Set<OrderStatus>> TRANSITIONS = new HashMap<>();
static {
TRANSITIONS.put(CREATED, Set.of(PAID, CANCELLED));
TRANSITIONS.put(PAID, Set.of(SHIPPED, CANCELLED));
// ...其他状态转换规则
}
public boolean canTransitionTo(OrderStatus target) {
return TRANSITIONS.getOrDefault(this, Set.of()).contains(target);
}
}
微服务中的幂等消费实践
Apache Camel实现
microservices-idempotent-consumer 模块演示了基于Apache Camel的幂等消费者模式：
from("activemq:orders")
.idempotentConsumer(header("JMSMessageID"),
memoryIdempotentRepository(200))
.to("bean:orderService?method=processOrder");
Spring Boot集成示例
在App.java中，通过三次重复调用验证幂等性：
// 重复创建请求
Request req = requestService.create(UUID.randomUUID());
requestService.create(req.getUuid()); // 第二次调用
requestService.create(req.getUuid()); // 第三次调用
// 数据库最终只保留1条记录
LOGGER.info("Nb of requests : {}", requestRepository.count()); // 输出结果: 1
生产环境注意事项
- 分布式ID生成：确保requestId全局唯一，推荐使用雪花算法
- 超时策略：Redis锁超时应大于业务最大处理时间
- 监控告警：通过Prometheus监控重复请求量，设置阈值告警
- 降级方案：极端情况下可启用本地缓存临时兜底
总结与最佳实践
| 方案 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 防重表 | 核心交易场景 | 强一致性 | 数据库压力大 |
| Redis锁 | 高并发场景 | 性能好 | 依赖Redis可用性 |
| 状态机 | 流程化业务 | 业务解耦 | 实现复杂度高 |
建议结合业务场景组合使用：支付接口采用"防重表+状态机"双重保障，普通查询接口使用Redis锁，消息消费场景采用idempotent-consumer模式。完整代码示例可参考项目microservices-idempotent-consumer模块及官方文档README.md。
点赞收藏本文，关注作者获取《Java分布式系统设计实战》系列下一篇：《分布式事务解决方案对比》
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
