古语云：“一而再，再而三，其效不二”

俗语讲：被虐千百遍，依然如初恋

数学符号：f(f(f(x))) = f(x)

即无论操作执行一次还是多次，其效果始终如一，不会有差异。这就是幂等性。

文章导读

什么是幂等性？

接口幂等性就是用户对于<code>同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。比如：公交车刷卡，用户上车后刷码支付扣款成功，如果用户再次点击按钮刷卡并扣款成功，用户查询余额返发现多扣钱了，流水记录也变成了两条,这就没有保证接口的幂等性。因此，当你重复刷卡时，会提示：刷码重复。

注意：数据库可能产生幂等性问题，但是幂等性问题不只发生在数据库。

什么场景需要幂等设计？

一般对数据要求比较高的场景，如：金钱交易、数据一致性至关重要的业务场景：

在线支付：当用户发起支付请求时，避免重复扣款。银行交易：确保同一笔交易不会因网络重试等原因被执行多次。票务系统：在线购票平台在用户购票时，检查所选座位是否已被重复预订。通信服务：如短信或通话服务，系统会检查是否已为相同内容的请求计费。任务调度：在定时任务或批处理系统中，确保不会因为任务重启或重试而重复执行相同的操作。用户注册：防止因重复提交表单而导致用户信息被创建多次。

如何产生幂等问题？

产生幂等性问题的原因主要有：

网络请求重试：网络波动或超时，客户端可能会重复发送相同的请求。用户界面重复提交：用户在用户界面上可能会不小心重复点击按钮，导致相同的请求被发送多次。消息队列重试机制：使用消息队列（如Kafka、RabbitMQ）时，消息可能会被重复消费。数据库并发操作：数据库的插入、更新和删除操作多个事务同时修改同一条记录，而没有使用适当的锁机制或事务隔离级别。外部系统API接口重试：对外提供的API接口可能由于调用方的重试逻辑，导致数据库操作被重复调用。其它......

下面我们简单做些案例说明。

表设计（前期准备）

我们先来设计一张订单表并模拟一些数据：

1、表结构：

2、字段说明：

order_id：作为订单的唯一标识，通常是一个全局唯一的ID，如使用UUID或分布式ID生成器（如Snowflake算法）生成。

user_id：标识下单的用户，用于关联用户信息。

product_id：标识被购买的商品，用于关联商品信息。

quantity：购买的商品数量。

order_status：订单当前状态，用于控制订单的业务流程，确保幂等性。例如，只有当订单状态为“待支付”时，支付操作才会被执行。

create_time：记录订单创建的时间戳。

pay_time：记录订单支付的时间戳，如果订单被支付，这个字段会被更新。

version：乐观锁的版本号，每次更新操作都会增加该字段的值，用于检测在业务处理期间订单是否被其他事务更新过。

3、业务规则：

订单支付：在支付操作前，先检查<code>order_status是否为“待支付”，若是，则执行支付逻辑，并更新order_status为“已支付”；如果不是，则拒绝支付，保持订单状态不变。

订单取消：在取消操作前，同样检查order_status，只有订单在特定状态下才允许取消操作。

插入订单：使用order_id作为唯一约束，防止重复插入相同订单。

乐观锁：在更新订单状态时，使用version字段来确保在读取和更新之间没有其他事务更改了订单，如果读取的version和数据库中的version不一致，则拒绝更新。

4、数据状态

幂等性解决方案

幂等性设计方案通常在分布式系统中，常见的幂等性设计方案如下：

1、唯一性约束

利用数据库的唯一性约束，如唯一索引或主键，来避免插入重复数据。

<code>mysql> INSERT INTO `mydb`.`orders` (`order_id`, `user_id`, `product_id`, `quantity`, `order_status`, `create_time`, `pay_time`, `version`) VALUES ('ORD-20231023-0001', 'USR-A123456', 'PRD-X123', 2, 0, '2023-10-23 10:15:30', NULL, 1);

ERROR 1062 (23000): Duplicate entry 'ORD-20231023-0001' for key 'orders.PRIMARY'

注意：业务上要求生成全局唯一的主键。且不是自增策略，否则在分库分表的场景下，不同的表之间主键互不关联。

2. 乐观锁

通过记录数据的版本号或时间戳，仅当数据未被其他事务修改时，才允许更新操作执行。每次更新数据时，版本号都会递增。

UPDATE orders

SET

  quantity = 1,

  order_status = 1,

  pay_time = '2024-04-30 10:20:00',

  version = version + 1

WHERE

  order_id = 'ORD-20231023-0001' AND

  version = 1;

效果演示：

如果 Session-01 已经提交了事务，Session-02 的更新操作将不会影响任何行，因为 version 已经从 1 增加到了 2。

3. 悲观锁

使用悲观锁，事务在读取数据时会锁定相应的数据行，直到事务结束（提交或回滚）。这可以防止其他事务在锁定期间修改这些数据，从而确保数据的一致性。

在执行读取操作时，使用 <code>SELECT ... FOR UPDATE 语句来锁定相关记录。

-- 锁定记录

SELECT * FROM orders WHERE order_id = 'ORD-20231023-0001' FOR UPDATE;

-- 执行业务逻辑

 UPDATE orders SET quantity = 1, order_status = 1, pay_time = '2023-10-23 10:20:00' WHERE order_id = 'ORD-20231025-0003';

效果演示：

由此可见，悲观锁确保每个事务也能安全地执行，而不会导致数据不一致的问题。但是，悲观锁可能会因为锁定机制而导致 <code>性能问题 ，尤其是在高并发的系统中，这可能会引起 锁争用和死锁 。

4. 分布式锁

在分布式系统中，使用分布式锁来保证同一时间只有一个实例处理特定消息或请求。

当前使用redis分布式锁案例实现，

<code>public class MyService {

    private final RedisDistributedLock lock;

    public MyService(Jedis jedis, String lockKey, int lockTimeout) {

        this.lock = new RedisDistributedLock(jedis, lockKey, lockTimeout);

    }

    public void executeInLock() {

        if (lock.tryLock()) {

            try {

                // 执行业务逻辑

            } finally {

                lock.unlock();

            }

        } else {

            // 处理无法获取锁的情况，例如重试或记录日志

        }

    }

}

这里顺便提一句，建议采用Lua脚本实现删除锁的逻辑，保证原子性。

public void unlock() {

        // 释放锁，使用Lua脚本来确保原子性

        String unlockScript = "if redis.call('get', KEYS[1]) == ARGV[1] then " +

                              "return redis.call('del', KEYS[1]) " +

                              "else " +

                              "return 0 " +

                              "end";

        jedis.eval(unlockScript, 1, lockKey, "1");

}

5. Token令牌机制

为每个请求生成一个唯一的Token，并在服务端进行校验，一旦处理了对应的请求，就丢弃该Token，避免重复处理。具体步骤：

1、服务端提供了发送 token 的接口。我们在分析业务的时候，哪些业务是存在幂等问题的， 就必须在执行业务前，先去获取 token，服务器会把 token 保存到 redis 中。

2、然后调用业务接口请求时，把 token 携带过去，一般放在请求头部。

3、服务器判断 token 是否存在 redis 中，存在表示第一次请求，然后删除 token,继续执行业务。

4、如果判断token不存在redis中，就表示是重复操作，直接返回重复标记给 client，这样就保证了业务代码，不被重复执行。

核心逻辑：

<code>// 服务端接口，接收请求并处理token

void do(String token) {

    if (Redis.exists(token)) {

       // 删除token，确保不会重复处理

        Redis.del(token); 

        // 执行具体的业务操作

        doSometing(); 

    } else {

        log.info(token); 

    }

}

注意：最好设计为先删除 token，如果业务调用失败，就重新获取 token 再次请求。可以在 redis 使用 lua 脚本完成这个操作

if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end

6. 状态机

使用状态机是判断业务流程，确保操作只执行一次。

状态机设计:

订单创建：订单初始化，状态为 PENDING（待支付）。

支付操作：当订单状态为 PENDING 时，允许执行支付操作，支付成功后状态变为 PAID（已支付）。

重复支付检查：如果再次尝试支付一个已经是 PAID 状态的订单，状态机将拒绝该操作，保持订单状态不变。

实现案例

public enum OrderStatus {

    PENDING, PAID, CANCELLED

}

public class Order {

    private OrderStatus status; // 订单当前状态

    // 其他订单属性...

    public Order() {

        this.status = OrderStatus.PENDING; // 初始化状态为待支付

    }

    // 执行支付操作

    public synchronized void pay() {

        if (this.status == OrderStatus.PENDING) {

            // 执行支付逻辑，如减少库存、扣款等

            this.status = OrderStatus.PAID; // 状态转变为已支付

        } else {

            // 如果订单不是在待支付状态，抛出异常或记录日志

            throw new IllegalStateException("Order can only be paid when status is PENDING");

        }

    }

    // 其他业务逻辑...

}

幂等性保证:

支付操作 pay 在订单状态不是 PENDING 时不会被执行，从而保证了幂等性。

如果有重复的支付请求，由于状态机的保护，第二次及后续的支付请求将不会改变订单状态，因此不会执行重复的支付逻辑。

7. 去重表

记录已经处理过的请求标识，对于重复的请求直接返回结果，而不再次执行业务逻辑。

1、去重表结构设计

表字段至少包括：

请求标识符：唯一标识一次请求。

创建时间：记录请求的时间戳。

处理状态：标识请求是否已处理，以及处理的结果。

2、设置过期策略

为了防止去重表无限增长，表中的记录可以设置过期时间。使用定时任务定期清理旧的请求记录。

实现案例：

1、检查去重表

在执行业务逻辑之前，检查去重表确定该请求是否已经被处理过。

boolean isDuplicate = checkDuplicateInDatabase(requestId);

2、处理请求

if (isDuplicate) {

    // 返回之前的结果或拒绝处理

    return previousResult;

} else {

    // 执行业务逻辑

    doSomthing();

    // 记录去重表

    saveRecord(requestId);

    // 返回新的结果

    return newResult;

}

注意事项：

数据一致性：确保去重表的更新与业务逻辑的执行保持一致性，避免出现数据不一致的情况。

8. 全局请求唯一ID

调用接口时，生成一个唯一 id，redis 将数据保存到集合中（去重），存在即处理过。

可以使用 nginx 设置每一个请求的唯一 id；

proxy_set_header X-Request-Id $request_id;