接口幂等性是防止重复提交、数据错乱的第一道防线，核心是识别并拦截同一请求的多次到达，确保业务逻辑只执行一次；常用方案包括Token机制、数据库唯一约束、Redis指纹去重及符合HTTP幂等语义的PUT/DELETE设计。
接口幂等性不是“锦上添花”，而是防止重复提交、数据错乱的第一道防线。核心思路很直接：识别并拦截同一请求的多次到达，确保业务逻辑只执行一次，后续调用返回一致结果。
用唯一请求标识（Token）控制前端提交
适用于用户主动触发的操作，比如下单、支付、表单提交。
- 后端在页面加载或提交前，生成一个短期有效的 Token（如 UUID），存入 Redis 并设置过期时间（建议比接口最大响应时间长 1.5–2 倍）
- 前端将该 Token 放入请求 Header（如 X-Idempotency-Token）或 Body 中一并提交
- 后端收到请求后，先用 SETNX 原子操作校验 Token 是否已存在；存在则直接返回首次成功结果（需提前缓存响应体），不存在则继续执行业务，并在成功后写入 Token 标识
- 注意：Token 应绑定关键业务上下文，例如 用户ID + 接口路径 + 业务主键（如订单号），避免跨用户或跨场景误判
靠数据库约束兜底，尤其对创建类操作
适合 POST 创建资源的场景，比如新增设备、注册账号、生成工单。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 在数据库表中为关键业务字段添加唯一索引，例如订单表的 user_id + order_no 或设备表的 sn（序列号）
- 业务代码中捕获唯一约束异常（如 MySQL 的 1062 错误），统一转换为“操作已存在”，返回原始成功结果而非报错
- 该方式简单可靠，但仅能防“最终重复”，不能阻止业务逻辑被多次执行（如扣款逻辑若在插入前已执行，就会出问题），所以要配合前置 Token 或状态校验
用 Redis 缓存请求指纹做轻量级去重
适合高频、低事务要求的接口，比如日志上报、状态心跳、配置同步。
- 对每次请求提取指纹：组合关键参数（如设备 ID + 指令类型 + 时间戳前 60 秒）做哈希（如 MD5 或 SHA-256）
- 以指纹为 Key，写入 Redis 并设 TTL（例如 60–300 秒），使用 SETNX + EXAT 命令保证原子性
- 写入失败即判定为重复请求，直接返回成功响应（或空响应）；写入成功才继续处理
- 注意避免指纹过于宽泛（如只用用户 ID）导致误拦，也避免过于精细（含毫秒级时间戳）失去去重意义
对更新/删除类操作，优先用幂等语义设计接口
HTTP 方法本身有幂等约定，应尽量贴合规范，减少额外防护负担。
- 新增用 POST，但更新必须用 PUT（带完整资源表示）、删除必须用 DELETE（带明确资源 ID）
- PUT 更新时，用乐观锁（如 version 字段或 update_time 时间戳）校验是否被并发修改，避免覆盖式更新引发脏写
- DELETE 删除时，即使资源已不存在，也应返回 200 或 204，而不是 404；这是幂等性的体现——效果一致（资源终态为“不存在”）
- 避免在 PUT/DELETE 中混入非幂等操作，例如“PUT /order/{id}/pay”这种伪更新，实际是发起新支付，应改用 POST
不复杂但容易忽略：幂等不是加个 Token 就完事，关键是把标识生命周期、业务执行边界、失败回滚策略串起来。Token 要能覆盖重试窗口，数据库约束要和业务逻辑顺序对齐，Redis 指纹要足够区分真实请求。三者常组合使用，而不是只选其一。
