接口幂等性的四种方案

1 什么是接口幂等性

接口幂等性是指一次和多次请求某一个资源对于资源本身应该具有相同的结果,即任意执行多次执行对资源本身所产生的影响与一次执行的影响相同。

2 为什么需要实现幂等性

  1. 前端重复提交表单;
  2. 用户恶意进行刷单;
  3. 接口超时重复提交;
  4. 消息进行重复消费;

3 引入幂等性对系统的影响

引入幂等性后有如下影响:

  • 把并行执行的功能改为串行执行,降低了执行效率;
  • 增加了额外控制幂等性的业务逻辑,复杂了业务功能
    所以在使用的时候需要考虑是否需要幂等性,一般情况下不需要引入幂等性

4 请求方法类型是否满足幂等性

  • GET:Get方法用于获取资源,不会对资源改变,满足幂等性;
  • POST:POST请求用于创建资源,不满足幂等性;
  • PUT:PUT请求用于修改资源,分情况而定,不执行累加的更新操作就满足幂等性;
  • DELETE:DELETE用于删除资源,删除一次资源和删除多次资源结果相同,满足幂等性;

5 如何实现幂等性

5.1 数据库唯一索引

数据库唯一索引能保证一张表中只能存在一条带该唯一索引的记录。
使用数据库唯一索引切记不能使用数据库自增主键来作为唯一索引,否则添加资源的时候也是无法保证幂等性的,而是使用分布式ID作为唯一索引,这样才能保证全局唯一性。

5.2 数据库乐观锁

数据库乐观锁只适用于执行更新操作的过程,可以在对应的数据库表中增加版本号表示,每次更新都带上这个版本号表示作为条件。这样每次更新带上版本号条件后就会判断当前的操作是否是重复操作。

5.3 防重复token令牌

针对客户端连续点击或者调用方法的超时重试等情况,例如提交订单,就可以用token的机制防止重复提交。
就是在调用方进入订单提交页面时先向服务端申请一个全局ID,然后带上这个全局ID一起发送给服务端,后端把这个token作为key,用户信息作为value,到Redis去查找是否存在这个key,如果存在就正常执行业务,并在执行业务后删除该key,不匹配就返回重复提交的信息。
在高并发情况下,执行Redis查找和删除命令需要保证原子性,其实现方法可以使用分布式锁来保证。

5.4 传递唯一序列号

传递唯一序列号就是每次向服务端请求的时候通过一个短时间的唯一序列号进行验证,这个序列号可以使服务端生成,然后到Redis里查询是否存在对应key的键值对,根据其结果:

  • 如果存在,就说明已经对该业务请求进行了处理,这时直接响应重复请求的错误消息。
  • 如果不存在,就以该key作为Redis的键存进去,同时设置过期时间。

猜你喜欢

转载自blog.csdn.net/qq_36986015/article/details/113587985