幂等（Idempotence）是计算机科学和数学中的一个重要概念，特别是在分布式系统和API设计中。幂等操作指的是无论执行多少次，其结果都与执行一次的结果相同。这种特性在处理重复请求、网络不稳定或系统故障恢复时非常有用，因为它可以确保操作的可靠性和一致性。
幂等的意义
- 重复请求处理：在网络请求中，由于超时或重试机制，同一个请求可能会被发送多次。如果操作是幂等的，那么多次请求不会导致数据不一致或产生副作用。
- 故障恢复：在系统故障恢复过程中，幂等操作可以确保重新执行的操作不会因为之前的执行而改变结果。
- 分布式系统：在分布式系统中，幂等性可以简化并发控制，减少锁的使用，提高系统的吞吐量和可靠性。
实现幂等的方法
实现幂等的方法取决于具体的业务场景和系统架构。以下是一些常见的实现策略：
-
唯一标识符（Idempotency Key） ：
- 为每个请求生成一个唯一的标识符（如UUID），并将其与请求一起发送。
- 服务端在处理请求前，先检查该标识符是否已经处理过。如果已经处理过，则直接返回之前的结果；否则，处理请求并记录标识符。
- 这种方法适用于大多数API请求，特别是写操作（如创建、更新）。
-
数据库唯一约束：
- 在数据库表中为关键字段设置唯一约束（如订单号、用户ID等）。
- 当尝试插入或更新数据时，如果违反唯一约束，则数据库会拒绝操作并返回错误。
- 这种方法适用于确保数据唯一性的场景，如防止重复订单、重复用户注册等。
-
乐观锁与悲观锁：
- 乐观锁：通过版本号或时间戳等机制实现。在更新数据时，检查版本号或时间戳是否与预期一致。如果一致，则更新数据并递增版本号；否则，拒绝更新。
- 悲观锁：在读取数据时锁定数据，防止其他事务修改。这种方法适用于并发冲突频繁的场景，但可能降低系统吞吐量。
- 乐观锁和悲观锁都可以用于实现幂等更新，但乐观锁通常更轻量级且适用于高并发场景。
-
状态机与条件判断：
- 根据业务逻辑设计状态机，并确保每个状态转换都是幂等的。
- 在处理请求时，先检查当前状态，然后根据状态决定是否执行操作。例如，如果订单已经处于“已完成”状态，则拒绝再次执行“完成订单”操作。
-
去重表或缓存：
- 创建一个去重表或使用缓存来记录已经处理过的请求标识符。
- 在处理请求前，先查询去重表或缓存。如果请求标识符已存在，则直接返回结果；否则，处理请求并记录标识符。
-
分布式锁：
- 在分布式系统中，可以使用分布式锁（如Redis锁、Zookeeper锁）来确保同一时间只有一个请求能够执行特定操作。
- 这种方法适用于需要强一致性的场景，但可能引入额外的性能开销。
示例
假设有一个创建订单的API，为了实现幂等性，可以采取以下步骤：
- 客户端为每个创建订单的请求生成一个唯一的订单号（Idempotency Key）。
- 客户端将订单号与其他请求参数一起发送到服务端。
- 服务端在处理请求前，先检查数据库中是否已经存在具有相同订单号的订单。
- 如果存在，则直接返回该订单的信息；否则，创建新订单并保存到数据库中。
通过这种方式，即使客户端多次发送相同的请求，服务端也只会创建一个订单，从而实现了幂等性。
| 实现方式 | 适用场景 | 说明 |
|---|---|---|
| 1. 唯一业务标识（幂等键） | 接口调用、下单、支付 | 通过唯一 requestId、orderNo、bizId 保证唯一性 |
| 2. 去重表（幂等记录表） | 消息消费、支付回调 | 在数据库中记录处理过的 唯一标识 |
| 3. 数据库唯一约束 | 插入类操作 | 用唯一索引防止重复插入 |
| 4. 乐观锁机制 | 更新类操作 | 检查版本号或状态，防止重复更新 |
| 5. Token 机制（一次性口令） | 防止重复提交表单 | 前端请求前向服务端申请 token，使用后失效 |
| 6. 分布式锁 | 高并发关键操作 | 使用 Redis/Zookeeper 保证同一时间只有一个线程执行 |
| 7. 状态机控制 | 有状态业务 | 例如订单从 “待支付”→“已支付”→“已完成”，重复支付时检查状态 |
