Try Everything Different In My Life.

「📝总结」从【重复消费】到【接口幂等】

2020.07.06

在之前做系统的过程中,出现过一次重复消费的情况。在引入消息队列之后,系统变得越来越复杂,接口设计的幂等性也是重要的考量之一

起因

在之前做过的项目中🔗记录一次线上重复消费的问题-接口幂等性,因为重复发送消费报文信息导致生成环境中消费的问题。

在项目使用消息队列之后,重复消息导致的重复消费也影响数据的正确性问题,所以接口在设计上要保证幂等性是必须的

幂等

外部操作系统都是通过系统提供的接口来操作,接口规范了接受的参数,系统按照传入的参数来做处理。在HTTP方法中,GET(查),DELETE(删除)是接口幂等的,无论操作多少次都不会对数据产生影响。UPDATE(更新)在更新不变数据的时候是幂等的,比如更新用户的名字,但是在某些情况下不是幂等的,如:更新商品的库存减少5个。POST(增加)是不幂等,操作一次就会增加数据。

上面说了幂等原因,下面说说需要做幂等的环境

  • 前端重复提交
  • 恶意仿造参数攻击
  • 接口超时重试
  • 消息重复消费

解决方案

token机制

在调用接口之前先申请一个token,然后将token带进去,后台验证token是否合法

数据库去重表

利用数据库的列的唯一性特点,在修改数据的时候加入id,数据库校验这个id是否存在

Redis

状态机

给业务加上状态机制,如订单已付款后就不能再支付

总结