/reqproc/处理中如何保证请求幂等性？

Question

在/reqproc/请求处理中，如何通过唯一请求ID和分布式锁机制协同实现幂等性？当客户端重试导致重复请求时，服务端如何基于请求ID校验防止重复处理？同时，在高并发场景下，若多个相同请求同时到达，仅靠数据库唯一索引可能引发竞争条件，此时结合Redis分布式锁与状态机控制，是否能有效避免资源重复消耗？该方案在节点宕机或锁过期时又可能存在哪些一致性风险？

Answer 1

一、幂等性设计的核心挑战与基础概念

在分布式系统中，/reqproc/请求处理路径的幂等性是保障数据一致性和用户体验的关键。当客户端因网络超时重试发送相同请求时，服务端若未做幂等控制，可能导致订单重复创建、账户重复扣款等问题。

实现幂等性的常见手段包括：

• 唯一请求ID（Request ID）：由客户端生成并随请求携带，服务端以此作为去重标识。
• 数据库唯一索引：基于业务主键或请求ID建立唯一约束，防止重复插入。
• 缓存层校验（如Redis）：利用内存快速判断请求是否已处理。
• 分布式锁机制：协调多个实例对同一资源的操作顺序。

然而，在高并发场景下，仅依赖数据库唯一索引可能引发“竞争窗口”问题——多个线程同时通过前置检查，几乎同时执行写入，导致唯一约束冲突或重复处理。

二、基于请求ID的幂等校验流程

服务端接收到/reqproc/请求后，首先解析请求体中的X-Request-ID头或字段。该ID应满足全局唯一性（如UUID v4），并在客户端重试时保持不变。

典型校验逻辑如下：

String requestId = request.getHeader("X-Request-ID");
if (StringUtils.isEmpty(requestId)) {
    throw new InvalidRequestException("Missing X-Request-ID");
}

// 查询该请求ID是否已存在处理记录
Boolean alreadyProcessed = idempotentService.isRequestProcessed(requestId);
if (alreadyProcessed) {
    return Response.ok().body(getCachedResult(requestId));
}

此阶段可在Redis中维护一个SET或HASH结构存储已处理的请求ID，并设置合理的TTL（例如24小时），避免无限膨胀。

三、高并发下的竞争条件与分布式锁介入

考虑以下并发场景：

时间点	线程A	线程B
T1	读取Redis：request_id未处理	读取Redis：request_id未处理
T2	进入业务处理	进入业务处理
T3	写入数据库成功	写入数据库失败（唯一索引冲突）

尽管最终只有一条数据入库，但线程B仍执行了完整业务逻辑（如调用第三方支付接口），造成资源浪费。

为此，引入Redis分布式锁进行串行化控制：

RLock lock = redissonClient.getLock("idempotent_lock:" + requestId);
try {
    boolean acquired = lock.tryLock(3, 10, TimeUnit.SECONDS);
    if (!acquired) {
        throw new ServiceUnavailableException("Failed to acquire lock");
    }

    // 再次确认是否已处理（双重检查）
    if (isAlreadyHandled(requestId)) {
        return getCachedResponse(requestId);
    }

    // 执行核心业务逻辑
    Object result = executeBusinessLogic(request);

    // 缓存结果与状态
    cacheResult(requestId, result);
    markAsProcessed(requestId);

    return Response.ok(result);
} finally {
    lock.unlock();
}

四、结合状态机控制提升可靠性

为增强幂等系统的可追踪性与容错能力，建议引入轻量级状态机模型管理请求生命周期：

1. PENDING：请求开始处理
2. PROCESSING：正在执行业务逻辑
3. SUCCESS：处理成功
4. FAILED：处理失败（可重试）
5. REJECTED：被拒绝（非法请求）

状态迁移受分布式锁保护，确保同一请求不会并发进入PROCESSING状态。

示例状态流转表：

当前状态	事件	新状态	动作
PENDING	start_processing	PROCESSING	获取锁，初始化上下文
PROCESSING	on_success	SUCCESS	释放锁，缓存结果
PROCESSING	on_failure	FAILED	记录错误，保留锁上下文用于重试分析
SUCCESS	retry_request	SUCCESS	返回缓存结果
*	invalid_request	REJECTED	标记并告警

五、潜在一致性风险与应对策略

尽管上述方案能显著降低重复处理概率，但在极端情况下仍存在一致性隐患：

graph TD A[客户端发送请求] --> B{服务端获取分布式锁} B -->|成功| C[执行业务逻辑] C --> D[写入数据库] D --> E[缓存结果+标记完成] E --> F[返回响应] B -->|失败| G[返回503或重定向] C --> H[节点宕机] H --> I[锁自动过期] I --> J[另一节点获取锁] J --> K[重复执行业务]

主要风险包括：

• 锁过期导致重复执行：若业务处理时间超过锁的TTL，其他节点可重新加锁，引发重复处理。
• 节点宕机未清理状态：原节点崩溃前未能完成状态更新，后续恢复后可能误判状态。
• 时钟漂移影响TTL精度：跨机房部署时NTP同步误差可能影响锁有效性判断。

缓解措施：

1. 采用Redlock算法或多节点Redis集群提升锁可靠性。
2. 设置锁TTL远大于预期最大处理时间，并配合异步续约（watchdog机制）。
3. 关键操作日志落盘，支持事后审计与补偿事务（如Saga模式）。
4. 使用带版本号的状态更新（CAS操作）防止脏写。
5. 对核心资源操作引入“预占-确认”两阶段模型（如库存预扣）。