最系统的幂等性方案：“一锁二判三更新”全解析

在分布式系统与高并发场景下，幂等性是保障业务数据一致性的核心设计原则。它要求同一操作无论执行多少次，最终结果都应保持一致。然而，实际开发中，网络延迟、重试机制、并发请求等问题常导致重复操作，引发数据错乱、资源浪费甚至业务纠纷。本文将系统阐述“一锁二判三更新”这一幂等性方案，通过分布式锁、状态判断与校验、条件更新三大核心步骤，为开发者提供一套可落地的解决方案。

一、锁：分布式锁的选型与实现

1. 为什么需要锁？

在并发场景下，多个请求可能同时到达服务端，若未对共享资源加锁，会导致重复操作。例如，用户重复提交订单时，若未加锁，可能生成多条订单记录，造成数据不一致。分布式锁的作用是确保同一时间只有一个请求能操作关键资源，从源头上避免并发冲突。

2. 分布式锁的选型

Redis分布式锁：基于SETNX命令实现，支持超时自动释放，适合大多数场景。需注意锁的续期问题（如Redisson的看门狗机制）。
Zookeeper分布式锁：通过临时顺序节点实现，可靠性高，但性能略低于Redis，适合对一致性要求极高的场景。
数据库唯一索引：通过表字段的唯一性约束（如订单号唯一）间接实现锁，但并发性能较差，适合低并发场景。

3. 代码示例（Redis分布式锁）

// 使用Redisson实现分布式锁
RLock lock = redissonClient.getLock("order_lock:" + orderId);
try {
    // 尝试加锁，等待时间5秒，锁自动释放时间30秒
    boolean isLocked = lock.tryLock(5, 30, TimeUnit.SECONDS);
    if (isLocked) {
        // 执行业务逻辑
        createOrder(orderId, userId);
    }
} catch (Exception e) {
    log.error("加锁失败", e);
} finally {
    if (lock.isHeldByCurrentThread()) {
        lock.unlock();
    }
}

二、判：状态判断与校验

1. 幂等性校验的核心逻辑

即使通过锁避免了并发冲突，仍需对操作状态进行二次校验，防止因锁超时释放或业务逻辑异常导致的重复操作。校验的核心是通过唯一标识（如订单号、请求ID）查询系统当前状态，判断是否已处理过该请求。

2. 校验策略

状态字段校验：在数据库中为业务表添加状态字段（如order_status），查询时判断状态是否为“已完成”。
唯一标识查询：通过唯一索引字段（如request_id）直接查询记录是否存在。
版本号控制：使用乐观锁机制，通过版本号（version）判断数据是否被修改。

3. 代码示例（状态校验）

// 查询订单状态
Order order = orderDao.findByOrderId(orderId);
if (order != null && "COMPLETED".equals(order.getStatus())) {
    throw new BusinessException("订单已处理，请勿重复提交");
}
// 若订单不存在或状态为未完成，继续处理
if (order == null) {
    order = new Order();
    order.setOrderId(orderId);
    order.setStatus("PROCESSING");
    orderDao.insert(order);
}

三、更新：条件更新与最终一致性

1. 条件更新的必要性

在状态校验通过后，需通过条件更新确保操作的原子性。例如，在更新订单状态时，需同时校验状态是否为“处理中”，避免其他线程已修改状态。

2. 条件更新的实现方式

数据库条件更新：使用UPDATE ... WHERE语句，通过状态字段或版本号限制更新范围。
CAS（Compare-And-Swap）操作：在内存中通过原子操作实现条件更新，适合高性能场景。

3. 代码示例（数据库条件更新）

// 条件更新订单状态
int updatedRows = orderDao.updateStatus(
    orderId, 
    "PROCESSING", // 当前状态
    "COMPLETED"  // 目标状态
);
if (updatedRows == 0) {
    throw new BusinessException("订单状态已变更，请刷新后重试");
}

四、完整方案示例：订单创建流程

结合“一锁二判三更新”，完整的订单创建流程如下：

加锁：通过分布式锁锁定订单ID，防止并发创建。
校验：查询订单状态，若已存在则直接返回。
条件更新：若订单不存在，插入新记录并更新状态为“处理中”；若存在但状态为未完成，则抛出异常。

public void createOrderWithIdempotency(String orderId, String userId) {
    RLock lock = redissonClient.getLock("order_lock:" + orderId);
    try {
        boolean isLocked = lock.tryLock(5, 30, TimeUnit.SECONDS);
        if (!isLocked) {
            throw new BusinessException("系统繁忙，请稍后重试");
        }
        // 状态校验
        Order order = orderDao.findByOrderId(orderId);
        if (order != null && "COMPLETED".equals(order.getStatus())) {
            throw new BusinessException("订单已处理，请勿重复提交");
        }
        // 条件更新
        if (order == null) {
            order = new Order();
            order.setOrderId(orderId);
            order.setUserId(userId);
            order.setStatus("PROCESSING");
            orderDao.insert(order);
        } else if (!"PROCESSING".equals(order.getStatus())) {
            throw new BusinessException("订单状态异常，请刷新后重试");
        }
        // 执行业务逻辑（如扣减库存、支付等）
        processOrder(order);
        // 最终状态更新
        orderDao.updateStatus(orderId, "PROCESSING", "COMPLETED");
    } catch (Exception e) {
        log.error("订单创建失败", e);
        throw e;
    } finally {
        if (lock.isHeldByCurrentThread()) {
            lock.unlock();
        }
    }
}

五、总结与建议

“一锁二判三更新”方案通过分布式锁控制并发、状态校验避免重复、条件更新保障原子性，形成了一套完整的幂等性解决方案。实际开发中，需根据业务场景选择合适的锁类型和校验策略，并注意以下细节：

锁的粒度：锁的键应与业务唯一标识强关联，避免锁范围过大导致性能下降。
超时与重试：合理设置锁的超时时间，避免因业务逻辑执行过长导致锁自动释放。
异常处理：对锁获取失败、状态校验失败等场景进行友好提示，避免用户困惑。

通过系统化的幂等性设计，可显著提升系统的可靠性与用户体验，为高并发场景下的业务稳定运行提供坚实保障。