重试时如何避免重复提交或幂等性问题？

Question

**问题：** 在分布式系统中，网络超时或服务暂时不可用常触发客户端/中间件自动重试（如OkHttp、Ribbon、Spring Retry），但若后端接口无幂等设计，一次业务请求可能被多次执行——例如重复扣款、订单重复创建、库存超卖。根本矛盾在于：**重试机制保障了可用性，却破坏了数据一致性**。典型场景包括：前端双击提交未防抖、消息队列消费失败反复重投、Saga事务中补偿动作未校验前置状态。如何在不牺牲可靠性的前提下，确保“无论调用一次还是多次，业务结果始终一致”？这要求从接口设计（如引入幂等Key）、存储层控制（唯一索引/状态机校验）、到链路协同（请求ID透传+服务端去重缓存）形成完整防御体系。

Answer 1

```html

一、幂等性本质：从“可重试”到“可重复”的语义跃迁

幂等性（Idempotency）在数学中指 f(f(x)) = f(x)；在分布式系统中，它被重新定义为：对同一业务请求（由唯一业务上下文标识），无论执行1次还是N次，其对外可见的业务状态变更结果完全一致。这不是简单的“不报错”，而是状态收敛——例如订单创建接口被调用3次，最终只生成1个有效订单且状态为“已创建”，其余2次返回200 OK或409 Conflict，而非插入新记录或抛出异常。该定义直指核心矛盾：重试提升可用性（A）却威胁一致性（C），而幂等是CAP权衡中锚定C的关键支点。

二、典型故障链路与根因分层建模

层级	触发场景	失效环节	无幂等后果
客户端	前端双击提交 + 无防抖/禁用按钮	HTTP请求重复发出	订单服务收到2个相同payReqId的支付请求
中间件	Ribbon超时（ConnectTimeout=1s）+ MaxAutoRetries=2	网络抖动导致3次调用透传至下游	库存服务执行3次扣减，超卖5件
消息层	Kafka Consumer重启 + offset未提交	同一条消息被重复消费	用户积分增加3次，多赠600分

三、防御体系四层架构：接口→存储→链路→治理

1. 接口契约层：强制要求所有外部可重试接口接收idempotency-key（如X-Idempotency-Key: ord_7f3a9b2e-8c1d-4e5f-ba72-1a2b3c4d5e6f），并校验其格式（UUIDv4）、时效（TTL≤24h）及业务语义（如含商户ID+时间戳哈希）
2. 存储控制层：在数据库建立UNIQUE INDEX (idempotency_key, status) WHERE status IN ('CREATED','PROCESSING')，利用DB原子性拦截重复写入
3. 链路协同层：通过OpenTracing透传trace-id与idempotency-key，网关层集成Redis缓存（key=idemp_key:ord_7f3..., value={status:SUCCESS, biz_id:ORD123456, ts:1717023456}，TTL=15min）
4. 治理监控层：ELK采集idempotency-key重复率指标，Prometheus告警当idemp_reject_rate > 0.5%持续5分钟

四、关键实现模式对比与选型决策树

graph TD
    A[请求到达] --> B{是否携带合法Idempotency-Key?}
    B -->|否| C[拒绝：400 Bad Request]
    B -->|是| D[查Redis缓存]
    D --> E{缓存命中?}
    E -->|是| F[返回缓存结果 200/409]
    E -->|否| G[尝试DB唯一索引INSERT]
    G --> H{DB约束冲突?}
    H -->|是| I[读取原记录返回]
    H -->|否| J[执行业务逻辑 → 更新状态]

五、生产级代码片段：Spring Boot幂等过滤器

@Component
public class IdempotencyFilter implements Filter {
    @Autowired private RedisTemplate<String, IdempotentResult> redisTemplate;
    @Autowired private JdbcTemplate jdbcTemplate;

    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) {
        HttpServletRequest request = (HttpServletRequest) req;
        String key = request.getHeader("X-Idempotency-Key");
        if (StringUtils.isBlank(key)) {
            ((HttpServletResponse) res).sendError(400, "Missing X-Idempotency-Key");
            return;
        }
        // 1. 缓存预检
        IdempotentResult cached = redisTemplate.opsForValue().get("idemp:" + key);
        if (cached != null && !cached.isExpired()) {
            writeResponse((HttpServletResponse) res, cached);
            return;
        }
        // 2. DB唯一键兜底（需提前建表：CREATE TABLE idemp_record (idemp_key VARCHAR(255) UNIQUE, biz_id VARCHAR(64), status TINYINT, created_at DATETIME DEFAULT NOW());）
        try {
            jdbcTemplate.update("INSERT INTO idemp_record(idemp_key, biz_id, status) VALUES (?, ?, ?)", 
                key, "TEMP", 0);
        } catch (DataIntegrityViolationException e) {
            // 冲突则查原记录
            cached = jdbcTemplate.queryForObject(
                "SELECT biz_id, status FROM idemp_record WHERE idemp_key = ?", 
                new Object[]{key}, 
                new BeanPropertyRowMapper<>(IdempotentResult.class));
            writeResponse((HttpServletResponse) res, cached);
            return;
        }
        chain.doFilter(req, res); // 放行执行业务
    }
}

六、反模式警示：5种看似合理实则危险的实践

• ❌ 仅用前端按钮置灰防重复提交（绕过API直调即失效）
• ❌ 将幂等Key设为时间戳（并发请求毫秒级相同导致冲突）
• ❌ Redis缓存永不设置TTL（内存泄漏+脏数据累积）
• ❌ 在事务外校验幂等性（DB回滚后缓存未清理，造成状态不一致）
• ❌ Saga补偿动作不校验前置状态（如退款前未确认订单已发货，导致资损）

七、演进路线图：从单体幂等到全域幂等治理

阶段1（0–3月）：核心支付/订单接口接入Redis+DB双校验；阶段2（4–6月）：全链路埋点idempotency-key，构建幂等健康度大盘；阶段3（7–12月）：将幂等能力下沉为Service Mesh Sidecar标准插件，自动注入校验逻辑；阶段4（长期）：基于Opentelemetry规范扩展idempotency_decision span tag，实现跨云、跨协议（HTTP/gRPC/Kafka）统一幂等治理。

```