网站一卡就重试,后端接口该怎么办?

312 阅读2分钟

接口幂等

什么情况需要处理幂等

对于数据只能处理有且仅有一次的业务场景,例如:支付订单,扣费的操作。对于同一个订单号,只能扣费一次。不论是经过接口调用,还是通过mq消费消息,已经扣费了,如果有相同的请求过来,必须保证最终扣费结果一致。 一般导致重复提交的场景: 前端用户重复提交:客户端卡顿,用户习惯多次点击页面按钮导致同一时间多次提交。 调用接口超时重试:调用接口是如果遇到网络抖动,导致请求发出了,返回接受超时,这时调用者并不知道执行结果,进行了重试。 MQ消费重复:消费端消费消息超时,消息重新入队,MQ将消息发送到其他消费端。

如何实现接口幂等

  • 天然幂等的接口

例如简单的查询接口,查询商品详情,无论查询多少次,也不会对查询的结果有影响。

  • 页面的重复提交

对于用户的重复提交,可以使用token机制避免。在后端生成全局唯一的token,存放在redis,前端请求带上token,后端接口接受到携带的token,判断redis是否存在,存在则删除并进行业务处理,不存在则表示token已处理过,是重复请求,不做处理。

  • 使用唯一标识

对于存在唯一标识的业务场景,在建表时需要建立唯一索引避免重复提交带来的脏数据。例如:用户名唯一,对用用户名做唯一索引约束。订单支付表,对订单id做唯一索引约束。

  • 乐观锁

通过判断更新时的数据是否跟当前预期更新的数据一致,即CAS原理,不一致则根据业务提示失败,一致才更新。例如:使用更新时间判断数据是否被修改,判断是否跟查询时拿到的更新时间一致。update product set name='newname' where id=1 and update_time='2020-02-20 11:11:11';

  • 状态机

对于业务数据存在多种状态的情况,这些状态的流转往往有不可逆的情况,在更新状态时需要判断当前状态是否符合期望,否则不更新或抛出异常。例如:update order set status='payed' where id=1 and status='paying';


公众号