接口幂等性
接口幂等性是指同一接口被多次重复调用时，最终产生的业务结果是一致的，不会因为重复调用而导致非预期的副作用。简单来说，就是 “多次调用等价于一次调用”。
- 举个例子理解：
非幂等场景： 用户点击 “支付” 按钮时，因网络延迟连续点击了 3 次，如果支付接口不幂等，可能会扣 3 次钱（产生 3 笔交易）。
幂等场景： 同样的连续点击 3 次，支付接口通过幂等设计，最终只会扣 1 次钱（仅 1 笔交易）。
接口幂等性的作用：
- 保证数据一致性：避免因重复调用导致的数据错误（如重复下单、多扣钱、重复创建资源等），是分布式系统、高并发场景中数据可靠的基础。
- 应对异常重试：网络波动、服务超时、节点故障等场景下，系统通常会自动重试请求（如分布式事务中的重试机制、前端因加载慢的重复提交）。幂等性确保重试不会破坏业务逻辑。
- 提升系统可靠性：降低因重复操作导致的业务异常（如用户投诉、财务对账错误），减少人工介入修复的成本。
- 适配分布式场景：在微服务、消息队列等分布式架构中，请求可能被重复消费（如消息重试），幂等性是保证分布式协作正确性的关键。
如何解决接口幂等性
解决接口幂等性的核心思路是：通过技术手段识别重复请求，并确保重复请求不会对业务产生副作用。具体方案需根据业务场景（如新增、更新、删除操作）和系统架构（如分布式、单机）选择。
常见方案如下：
- 基于唯一标识（幂等 ID）的方案
原理：
- 客户端发起请求时，生成一个全局唯一的幂等 ID（如 UUID、雪花 ID、业务单号 + 时间戳等），并携带在请求中（如请求头、参数）。
- 服务端接收请求后，先判断该幂等 ID 是否已处理过（可通过数据库、Redis 等存储）：
若未处理过：正常执行业务逻辑，处理完成后记录该幂等 ID（标记为 “已处理”）。
若已处理过：直接返回之前的处理结果，不重复执行业务。
适用场景：
支付、转账、下单等新增操作（防止重复创建资源）。
消息队列消费（防止消息重复消费）。
优点：
实现简单，兼容性强，适用于分布式系统。
可追溯重复请求（通过幂等 ID 日志）。
注意：
幂等 ID 需保证全局唯一（避免不同请求 ID 冲突）。
存储幂等 ID 的介质需可靠（如 Redis 需持久化，数据库需事务保证）。
- 基于版本号（乐观锁）的方案
原理：
- 针对更新操作，在数据实体中增加一个version（版本号）字段，初始值为 0。
- 客户端查询数据时，获取当前版本号；更新时，将版本号作为条件传入（如UPDATE table SET ... WHERE id = ? AND version = ?）。
- 服务端执行更新时，若版本号匹配，则更新数据并将version+1；若版本号不匹配（说明已被其他请求更新），则拒绝本次更新，返回失败。
适用场景：
订单状态更新、用户信息修改等更新操作（防止并发重复更新）。
优点：
无锁设计，并发性能好，适合高并发场景。
能有效避免 “覆盖更新” 问题（如 A、B 同时更新，A 的结果被 B 覆盖）。
注意：
仅适用于更新操作，不适用于新增（新增时无版本号）。
客户端需处理更新失败的情况（如重试前重新获取最新版本号）。
- 基于状态机的方案
原理：
- 业务数据存在明确的状态流转规则（如订单状态：待支付→已支付→已发货→已完成），且状态转换不可逆。
- 重复请求时，若当前状态与目标状态的 “前置条件” 不匹配，则拒绝执行。例如：订单已处于“已支付”状态，重复调用 “支付” 接口时，因状态不符合“待支付”的前置条件，直接返回成功（或提示“已支付”）。
适用场景：
有严格状态流转的业务（如订单、工单、流程审批）。
优点：
符合业务逻辑，无需额外存储（依赖现有状态字段）。
天然防重复（状态不可逆）。
注意：
状态设计需严谨，避免状态流转漏洞（如遗漏中间状态）。
- 防重表方案
原理：
- 新建一张 “防重表”，核心字段为幂等 ID（设为唯一索引），其他字段可包含业务 ID、处理状态等。
- 服务端处理请求时，先向防重表插入当前幂等 ID：
若插入成功（无重复）：执行业务逻辑，完成后更新防重表状态为 “已处理”。
若插入失败（唯一索引冲突，说明重复请求）：直接返回之前的结果。
适用场景：
新增资源（如创建订单、生成券码），需严格保证唯一性。
优点：
依赖数据库唯一索引，可靠性高（数据库事务可保证原子性）。
缺点：
需额外维护防重表，增加存储成本。
高并发下可能因索引冲突导致性能损耗。
- 令牌（Token）机制
原理：
- 预生成令牌：客户端发起业务请求前，先调用 “获取令牌” 接口，服务端生成一个唯一 Token（如 UUID），存入 Redis（设置有效期），并返回给客户端。
- 携带令牌请求：客户端发起实际业务请求时，携带该 Token。
- 验证令牌：服务端接收请求后，先从 Redis 中删除 Token（原子操作，如DEL token）：
若删除成功（Token 存在）：说明是首次请求，执行业务。
若删除失败（Token 不存在）：说明是重复请求，拒绝处理。
适用场景：
前端表单提交（防止用户重复点击）、API 接口防刷。
优点：
令牌一次性有效，安全性高（避免 Token 泄露后被重复使用）。
缺点：
多一次 “获取令牌” 的请求，增加交互成本。
需设置合理的 Token 有效期（避免过期导致正常请求失败）。
- 分布式锁方案
原理：
- 利用 Redis、ZooKeeper 等实现分布式锁，以幂等 ID 为锁键。
- 服务端处理请求时，先尝试获取锁：
若获取成功：执行业务逻辑，完成后释放锁。
若获取失败：说明有其他线程正在处理该请求，等待或直接返回结果。
适用场景： 高并发分布式环境下的写操作（如秒杀下单）。
优点： 解决分布式系统中并发重复处理的问题。
缺点： 需处理锁超时、死锁等问题，实现复杂度较高。