本文由 千趣源码 – qianqu 发布，转载请注明出处，如有问题请联系我们！重试机制的隐秘战场：Java中一次被忽略的幂等性危机
在Java应用开发的日常中，网络调用、数据库写入、消息投递等操作常因瞬时故障而失败。于是，“重试”成了工程师手中最顺手的救火工具——加个@Retryable注解，配个指数退避策略，问题仿佛迎刃而解。然而，就在某次生产环境凌晨三点的告警风暴里，订单系统突然生成了17笔重复支付记录，财务对账单上赫然出现一串无法解释的“幽灵交易”。事后复盘日志，唯一标识字段java_1_3_6a17b4eda0f967.78146409像一枚冰冷的指纹，精准指向那次被盲目重试击穿的业务边界。
这并非偶然。Java生态中大量重试方案（如Spring Retry、Resilience4j、甚至自研while循环）默认只解决“可用性”问题，却对“正确性”保持沉默。当一次HTTP请求因超时中断，客户端无法判断服务端究竟处于何种状态：是请求根本未抵达？还是已处理成功但响应丢失？抑或中途崩溃导致部分执行？此时若无幂等设计兜底，重试便从容错机制异化为数据污染源。
以一个典型电商扣减库存场景为例：
```java
@Transactional
public void deductStock(Long skuId, Integer quantity) {
Stock stock = stockMAPPer.selectById(skuId);
if (stock.GETAvailable() < quantity) {
throw new InsufficientStockException();
}
stock.setAvailable(stock.getAvailable() - quantity);
stockMapper.updateById(stock);
}
```
表面看事务保障了ACID，但若该方法被@Retryable标注且发生重试，两次调用将先后进入事务——第一次成功扣减后，第二次仍能查到“足够库存”（因第一次事务尚未提交或已提交但缓存未失效），最终导致超卖。更隐蔽的是，若底层使用Redis分布式锁实现库存预占，重试可能绕过锁校验逻辑，让并发控制形同虚设。
破局关键在于将“重试”与“幂等”视为共生体而非并列选项。真正的解决方案需三层防御：
**第一层：请求级幂等标识**。在api入口强制校验唯一业务ID（如订单号、支付流水号），结合Redis SETNX + 过期时间实现“操作令牌”。Java中可封装为通用切面：
```java
@Aspect
public class IdempotentAspect {
@Around("@annotation(idempotent)")
public Object checkIdempotence(ProceedingJoinPoint pjp, Idempotent idempotent) {
String key = generateKey(pjp); // 如 "idempotent:" + orderId
Boolean exists = redisTemplate.opsForValue().setIfAbsent(key, "1", Duration.ofMinutes(30));
if (!Boolean.TRUE.equals(exists)) {
throw new IdempotentException("Duplicate request");
}
return pjp.proceed();
}
}
```
**第二层：状态机驱动**。避免“执行-再执行”思维，转向“状态跃迁”范式。例如支付流程应定义PENDING→PROCESSING→SUCCESS/FAILED状态，重试时先查询当前状态，仅对PROCESSING状态发起补偿，而非无差别重放原始动作。
**第三层：存储层防重**。在数据库层面通过唯一约束拦截（如联合索引`order_id+operation_type`），配合乐观锁版本号更新，使重复操作在持久化阶段即被拒绝。这虽增加DB压力，却是最终防线。
值得警惕的是，某些框架的“自动重试”存在认知陷阱。Spring Retry在抛出特定异常时触发重试，但若异常由事务回滚引发（如RollbackException），重试可能在新事务中重复执行——而开发者往往误以为“事务已回滚，重试安全”。实则原事务的副作用（如外部HTTP调用、MQ发送）可能已不可逆。
java_1_3_6a17b4eda0f967.78146409这个看似随机的标识，本质是系统在混沌中留下的求救信号。它提醒我们：在分布式系统的复杂性面前，重试不是银弹，而是需要精密校准的手术刀。每一次盲目重试，都在透支系统的可信度；每一次幂等设计，都是对用户信任的郑重承诺。当代码不再满足于“跑起来”，而开始追问“是否总能正确运行”，那才是真正工程成熟的起点。
