防止幂等与重复提交

幂等性机制设计

幂等性要求无论相同请求被执行多少次，结果都应一致且没有副作用。为实现这一点：

1. 唯一请求标识

方法：客户端生成一个全局唯一的请求标识符（如 UUID），并在每次请求中附带该标识。

• 服务端逻辑：

  • 检查请求是否已经处理（基于请求标识符）
  • 如果检测已经处理过，直接放回处理过的结果
  • 如果没有处理过，则处理并记录请求标识符及其结果。

2. 状态校验

方法：对资源的当前状态进行校验，确保状态变更仅发生在满足特定条件时。

• 例如：提交订单时，校验订单状态是否为“待支付”。

适用场景：适合业务逻辑明确的流程性操作。

3. 乐观锁

方法：在更新资源时，使用版本号或时间戳进行校验

1. 查询时带回资源的版本号。
2. 更新时校验版本号是否一致。
3. 若版本号一致则更新，并将版本号递增。

防重复提交机制

为了防止用户重复点击或网络重试造成重复提交，可以采用以下措施：

1. 短时间内限制

方法：为用户的特定操作设置冷却时间（如 3 秒）。

2. Token校验

方法：

• 在页面加载时生成一个唯一的 Token。
• 提交时要求附带 Token。
• 服务端验证 Token 的唯一性，并在使用后立即失效。

适用场景：表单提交、支付等一次性操作。

3. 幂等性接口

结合幂等性设计和请求标识符：

方法：将每个请求与特定的业务操作绑定，重复请求返回同一结果。

实现：使用请求标识符或操作记录数据库进行判断。

数据层面支持

1. 唯一约束

方法：在数据库中为关键字段（如订单号、业务流水号等）添加唯一约束
作用：从底层确保相同操作不会重复插入或更新。

2. 事务管理
   方法：确保同一事务中的操作要么全部成功，要么全部回滚。
   工具：依赖数据库的事务支持（如 MySQL 的事务隔离级别）。

分布式场景下的处理

在分布式系统中，防止重复提交需要特殊设计：

1. 分布式锁

工具：使用 Redis、Zookeeper 等工具实现分布式锁。
作用：确保同一资源在同一时刻只允许一个操作。

2. 消息去重

方法：在消息队列（如 Kafka、RabbitMQ）中，使用消息的唯一标识进行去重处理
适用场景：异步操作

3. 幂等表

方法：创建一张记录幂等请求的表，存储请求标识符及其处理结果
优点：适合需要记录操作历史的系统。