幂等与事务：分布式系统的双保险

在设计分布式系统或微服务架构时，接口的幂等性和事务一致性是两个核心概念。

❌ 错误认知：

“我用了一个数据库事务，包含了外调 + 更新表，失败就回滚，所以是安全的。”

✅ 现实情况：

数据库事务无法包含外部调用（外调）！

• 数据库事务只能控制本地数据库操作。
• 外部调用（如调用微信支付、发短信、调第三方API）不在事务控制范围内。
• 一旦外调发出，即使你后面 rollback 本地事务，外部服务已经执行成功了。

举个例子：

@Transactional
public void pay(Order order) {
    // 1. 调用微信支付（外部系统）
    wechatPayService.pay(order.getAmount());  // ✅ 已调用成功，钱已扣

    // 2. 更新本地订单状态
    orderMapper.updateStatus("PAID"); // ❌ 这里抛异常，事务回滚
}

结果：

• 本地订单状态回滚为“未支付”。
• 但用户已经被扣款了！
• 用户刷新页面，发现“未支付”，可能再次点击支付 → 重复扣款！

👉 所以：这不是事务能解决的问题，必须靠幂等设计来防止重复支付。

一、什么是幂等性？

幂等性（Idempotency）是指：无论一个操作执行一次还是多次，其结果都是一样的。对系统状态的影响是相同的。

例如：

• GET /user/1 是幂等的（读操作）。
• PUT /user/1 是幂等的（全量更新）。
• POST /order 通常不是幂等的（创建新资源）。
• DELETE /user/1 是幂等的（删除后再次删除无影响）。

---

二、如何实现一个“外调 + 更新表”接口的幂等性？

假设接口逻辑如下：

public void processOrder(OrderRequest request) {
    // 1. 调用外部支付系统
    PaymentResult result = externalPaymentService.pay(request.getAmount());
    
    // 2. 更新本地订单状态
    orderRepository.updateStatus(request.getOrderId(), "PAID");
}

这个接口存在两个问题：

1. 外部调用可能成功，但本地更新失败。
2. 接口被重复调用（如网络超时重试），导致重复支付。

问题一：外调的四种典型结果

外调结果	本地更新	系统状态	问题
✅ 成功	✅ 成功	一致	正常流程
✅ 成功	❌ 失败	不一致（外部已生效，本地未记录）	需要补偿
❌ 失败	✅ 成功	不一致（本地更新了，但外部没生效）	需要回滚/修正
❌ 失败	❌ 失败	一致	可重试或报错

问题二：即使事务成功，客户端也可能重复发起请求

这是幂等最核心的场景：“客户端不知道你成功了”，例如以下场景：

1. 用户点击“支付”按钮。
2. 服务端收到请求，开始处理（外调 + 更新）。
3. 处理耗时较长（比如 5 秒），客户端超时。
4. 客户端认为“失败”，自动重试或用户手动刷新 → 第二次请求发出。
5. 服务端第一次请求其实成功了，第二次又执行一遍 → 重复操作。

即使第一次的事务完全成功，客户端不知道，所以它会重试。

📌 事务只能保证“一次请求”内的原子性，但无法防止“多次请求”带来的重复执行。

这就是幂等要解决的问题：无论客户端发几次请求，结果只生效一次。

---

实现幂等的关键思路：

✅ 1. 引入唯一标识（幂等Key）

• 客户端在请求时携带一个全局唯一ID（如 idempotency-key 或 requestId）。
• 服务端使用该ID作为幂等判断依据。

// 伪代码
String requestId = request.getRequestId();
if (idempotentCache.exists(requestId)) {
    return idempotentCache.getResult(requestId); // 返回缓存结果
}

// 标记请求已处理
idempotentCache.set(requestId, "PROCESSING");

try {
    // 执行外调 + 更新
    PaymentResult result = externalPaymentService.pay(...);
    orderRepository.updateStatus(...);
    
    // 缓存成功结果
    idempotentCache.set(requestId, result, TTL);
} catch (Exception e) {
    idempotentCache.delete(requestId); // 清理状态，允许重试
    throw e;
}

注意：idempotentCache 可以是 Redis，Key 为 idempotency:{requestId}，设置合理的过期时间（如 24 小时）。

✅ 2. 基于业务状态机的幂等判断

• 在更新数据库前，先查询当前状态。
• 如果订单已经是“已支付”，则直接返回成功，不再外调。

Order order = orderRepository.findById(orderId);
if ("PAID".equals(order.getStatus())) {
    return; // 幂等：已支付，无需重复处理
}

✅ 3. 结合数据库唯一约束

• 在数据库中为 requestId 字段添加唯一索引。
• 插入或更新时，利用数据库的唯一性约束防止重复操作。

ALTER TABLE orders ADD CONSTRAINT uk_request_id UNIQUE (request_id);

✅ 4. 使用分布式锁 + 状态检查

• 在处理前加锁（如 Redis 分布式锁），防止并发重复处理。
• 加锁后再次检查状态，避免并发问题。

---

三、什么场景需要实现幂等？

场景	是否需要幂等	原因
客户端重试机制	✅ 必须	网络超时、服务端无响应时，客户端可能重试
消息队列消费	✅ 必须	消息可能重复投递（如 Kafka 重平衡）
第三方回调	✅ 必须	支付宝、微信支付等回调可能多次
定时任务	✅ 建议	防止任务重复执行导致数据错乱
前端重复提交	✅ 建议	用户快速点击“提交”按钮

结论：只要存在重复请求可能的场景，就必须考虑幂等性。

---

四、什么场景需要实现事务一致性？

事务一致性是指：多个操作要么全部成功，要么全部失败，保持数据的一致状态。

需要事务一致性的典型场景：

场景	是否需要事务一致性	说明
扣减库存 + 创建订单	✅ 必须	不能出现“库存扣了但订单没创建”
转账操作（A减钱，B加钱）	✅ 必须	必须保证原子性
外调成功 + 本地状态更新	✅ 强烈建议	防止“支付成功但订单未更新”
跨表更新（如订单+物流）	✅ 建议	避免数据不一致

但注意：外调 + 本地更新很难用本地事务保证一致性！

因为：

• 外部服务不在你的事务控制范围内。
• 本地事务提交后，外调可能失败。
• 外调成功后，本地事务可能回滚。

---

五、如何解决“外调 + 更新表”的事务一致性？

方案 1：本地消息表（Local Message Table）

• 将外调请求记录到本地数据库（带状态）。
• 启动定时任务或消息队列异步处理外调。
• 外调成功后更新状态。

优点：强一致性（依赖本地事务）
缺点：复杂度高，需要轮询

方案 2：可靠消息最终一致性（MQ）

• 发送消息前，先写入本地数据库（或使用事务消息）。
• 消费者执行外调 + 更新本地状态。
• 利用 MQ 的重试机制保证最终一致。

适用：异步场景，允许短暂不一致

方案 3：TCC（Try-Confirm-Cancel）

• Try：预留资源（如冻结金额）
• Confirm：确认操作（外调成功后提交）
• Cancel：取消预留

适合高一致性要求场景，但开发成本高

方案 4：Saga 模式

• 将操作拆分为多个可补偿事务。
• 如果外调失败，执行补偿操作（如退款）。

适合长流程、跨服务场景

---

六、总结：幂等 vs 事务一致性

维度	幂等性	事务一致性
目标	防止重复操作	保证多操作原子性
触发原因	重试、重复请求	数据逻辑依赖
实现方式	唯一ID、状态机、缓存、唯一索引	本地事务、TCC、Saga、消息队列
典型场景	支付回调、重试请求	转账、下单扣库存
是否必须	在重试场景下必须	在数据强依赖场景下必须

---

七、实际建议

1. 所有对外接口都应设计为幂等的，尤其是涉及写操作的。
2. 对于“外调 + 更新表”：
   • 优先使用 唯一请求ID + 状态机 + 缓存 实现幂等。
   • 使用 本地消息表或可靠MQ 保证最终一致性。
3. 不要依赖本地事务来控制外部调用的结果。
4. 记录详细日志，便于排查重复或不一致问题。

这是一个非常好的问题，触及了分布式系统设计中的核心概念。你提到：

“如果实现了事务一致性，失败了留在当前页面且回滚全部操作，为什么还需要幂等？”

乍一看似乎有道理：既然事务能回滚，保证了原子性，那不就天然防止了部分成功的问题吗？为什么还要额外做幂等？

下面我们从事务的边界、客户端行为和真实网络环境三个维度来深入解释：即使有事务一致性，幂等仍然是必需的。

---

✅ 正确做法：事务 + 幂等 一起用

public Result pay(String orderId, String requestId) {
    // 1. 幂等检查
    if (idempotentService.isProcessed(requestId)) {
        return idempotentService.getResult(requestId); // 返回上次结果
    }

    // 2. 加锁或标记处理中
    idempotentService.markProcessing(requestId);

    try {
        // 3. 开启事务（仅对本地操作）
        databaseService.updateOrderStatus("PAYING");

        // 4. 外部调用（不在事务内，但需幂等）
        boolean paid = externalService.pay(orderId);
        if (!paid) {
            throw new BusinessException("支付失败");
        }

        // 5. 更新本地状态
        databaseService.updateOrderStatus("PAID");

        // 6. 记录成功结果（幂等）
        idempotentService.markSuccess(requestId, Result.success());

        return Result.success();

    } catch (Exception e) {
        // 事务回滚（如果有）
        idempotentService.markFailed(requestId);
        throw e;
    }
}

---