2. 幂等性基础理论：幂等性的数学定义、HTTP幂等性语义、常见幂等性实现模式
2.1 幂等性的数学定义
幂等性（Idempotence）源自抽象代数，描述一个操作执行多次与执行一次产生相同结果的性质。在分布式系统与API设计中，幂等性是保证数据一致性的核心约束。
数学定义： 对于函数 f : X → X，若对于所有 x ∈ X，都有 f(f(x)) = f(x)，则称 f 为幂等函数。
通俗理解：无论调用多少次，系统状态在第一次调用后不再因重复调用而发生额外变更。例如：将某个订单状态设置为“已支付”，重复设置不会改变其最终状态。
2.2 HTTP幂等性语义
HTTP/1.1 规范（RFC 7231）对常见方法的幂等性做了明确区分。下表总结了核心方法的幂等性特征：
| HTTP方法 | 幂等性 | 安全性（不修改资源） | 典型语义 |
|---|---|---|---|
| GET | 是 | 是 | 检索资源，无副作用 |
| HEAD | 是 | 是 | 获取响应头，无响应体 |
| OPTIONS | 是 | 是 | 查询服务器支持的HTTP方法 |
| PUT | 是 | 否 | 全量替换资源，多次调用结果一致 |
| DELETE | 是 | 否 | 删除资源，首次删除后后续返回相同状态 |
| POST | 否 | 否 | 创建资源或提交数据，每次可能产生新资源 |
| PATCH | 否（默认） | 否 | 部分更新，需配合幂等令牌实现 |
关键区分： 幂等性不等于安全性。DELETE 是幂等的但不安全（修改资源）；GET 既是幂等的又是安全的。幂等性关注的是重复调用的副作用，安全性关注的是是否修改资源。
2.3 常见幂等性实现模式
在异步导出任务场景中，客户端可能因网络超时、服务端处理延迟等原因发起重试。以下四种模式是业界最常用的幂等性实现方案：
- 唯一请求ID（Idempotency Key）模式：客户端为每个请求生成全局唯一ID，服务端缓存该ID及处理结果，重复请求直接返回缓存结果。
- 乐观锁（版本号）模式：资源附带版本号或时间戳，更新时校验版本是否匹配，不匹配则拒绝更新。
- 状态机模式：将业务状态流转定义为有限状态机，只有符合前置状态的操作才允许执行，重复请求因状态不匹配而被忽略。
- 去重表模式：利用数据库唯一索引或分布式锁，对请求特征（如业务单号）进行去重，保证同一特征只处理一次。
下表对比了四种模式在异步导出任务中的适用性：
| 模式 | 核心机制 | 异步导出场景适用性 | 典型挑战 |
|---|---|---|---|
| 唯一请求ID | 客户端生成UUID，服务端缓存 | 高（推荐） | 缓存过期策略、分布式一致性 |
| 乐观锁 | 资源版本号递增校验 | 中 | 需资源本身支持版本字段 |
| 状态机 | 状态流转约束 | 高 | 状态定义需完整覆盖所有路径 |
| 去重表 | 数据库唯一索引 | 中 | 高并发下索引冲突、锁竞争 |
2.4 幂等性校验的核心流程
下图展示了基于唯一请求ID的幂等性校验在异步导出任务中的典型交互流程：
2.5 幂等性在异步导出任务中的特殊挑战
异步导出任务与同步API不同，其幂等性校验面临以下独特问题：
- 任务状态延迟：导出任务可能处于“处理中”状态，此时重复请求不应触发新任务，但也不能返回最终结果。
- 结果过期：导出文件可能设置了有效期，过期后重复请求是否需要重新生成？这需要业务语义上的幂等性定义。
- 超时与重试：客户端在超时后重试，服务端可能正在处理中，需要区分“未处理”和“处理中”两种状态。
实践注意： 幂等性校验不能仅依赖客户端生成的Key，服务端必须对Key的格式、有效期、重复提交间隔做校验。在分布式部署中，幂等缓存需要跨节点同步或使用集中式缓存（如Redis），否则可能出现同一Key在不同节点上被重复处理的情况。
2.6 幂等性校验的数学抽象与状态机映射
将幂等性校验映射为有限状态机，可以更严谨地描述异步导出任务的行为。下图展示了导出任务的状态机模型：
通过状态机约束，幂等性校验从“是否处理过”的二元判断，扩展为“当前状态是否允许重复处理”的多态判断，更贴合异步导出任务的真实业务场景。