关于接口幂等性问题的简单总结

关于接口幂等性问题的简单总结

在业务中需要考虑接口幂等性的地方一般都是存在接口重复请求的逻辑

  • 前端重复提交:提交订单,用户快速重复点击多次,造成后端生成多个内容重复的订单。
  • 接口超时重试:对于给第三方调用的接口,为了防止网络抖动或其他原因造成请求丢失,这样的接口一般都会设计成超时重试多次。
  • 消息重复消费:MQ消息中间件,消息重复消费。

对于和web端交互的接口,我们可以在前端拦截一部分,例如防止表单重复提交,按钮置灰、隐藏、不可点击等方式。

但是前端做控制实际效益不是很高,那么后端要实现分布式接口的幂等性有哪些策略方式呢?

  • Token机制

    针对前端重复连续多次点击的情况,例如用户购物提交订单,提交订单的接口就可以通过 Token 的机制实现防止重复提交。
    在这里插入图片描述

  • Redis

    Redis实现的方式就是将唯一序列号作为Key,value可以是你想填的任何信息。唯一序列号也可以是一个字段,例如订单的订单号,也可以是多字段的唯一性组合。(当然这里需要设置一个 key 的过期时间,否则 Redis 中会存在过多的 key。)具体步骤和上面的Token机制差不太多。调用具体业务逻辑之前先判断Redis中有无key,没有就add一个key,有就代表重复请求。

  • 状态机

    对于很多业务是有一个业务流转状态的,每个状态都有前置状态和后置状态,以及最后的结束状态。以订单为例,已支付的状态的前置状态只能是待支付,而取消状态的前置状态只能是待支付,通过这种状态机的流转我们就可以控制请求的幂等。假设当前状态是已支付,这时候如果支付接口又接收到了支付请求,则会抛异常或拒绝此次处理。

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值