接口幂等性如何设计 一、幂等性概念 一个请求方法,如果被请求多次和被请求一次效果相同,就认为是幂等的 二、适用场景 1、表单重复提交 2、网络波动引起重复请求 3、接口重试机制 4、消息重复消费 三、常见的解决方案 1、唯一索引,防止新增脏数据。 利用数据库唯一索引重复新增报错的机制,当然为了避免报错体验不友好,在新增前利用业唯一业务字段再查询一次,数据如果已经存在了返回结果即可 2、token机制
具体流程步骤: 1、客户端会先发送一个请求去 token,服务端会生成一个全局唯一的 ID 作为 token 保存在 redis 中,同时把这个 ID 返回给客户端 2、客户端第二次调用业务请求的时候必须携带这个 token 3、服务端会校验这个 token,如果校验成功,则执行业务,并删除 redis 中的 token 4、如果校验失败,说明 redis 中已经没有对应的 token,则表示重复操作,直接返回指定的结果给客户端 注意: 1、对 redis 中是否存在 token 以及删除的代码逻辑建议用 Lua 脚本实现,或有重试机制保证删除成功保证原子性 2、全局唯一 ID 可以用百度的 uid-generator、美团的 Leaf 去生成 3、基于redis实现 这种实现方式是基于 SETNX 命令实现的SETNX key value:将 key 的值设为 value , 当且仅当 key 不存在。若给定的 key 已经存在,则 SETNX 不做任何动作。 该命令在设置成功时返回 1,设置失败时返回 0。示意图如下:
具体流程步骤: 1、客户端先请求服务端,会拿到一个能代表这次请求业务的唯一字段 2、将该字段以 SETNX 的方式存入 redis 中,并根据业务设置相应的超时时间 3、如果设置成功,证明这是第一次请求,则执行后续的业务逻辑 4、如果设置失败,则代表已经执行过当前请求,直接返回 4、状态机 对于很多业务是有一个业务流转状态的,每个状态都有前置状态和后置状态,以及最后的结束状态。 例如流程的待审批,审批中,驳回,重新发起,审批通过,审批拒绝。订单的待提交,待支付,已支付,取消。 以订单为例,已支付的状态的前置状态只能是待支付,而取消状态的前置状态只能是待支付,通过这种状态机的流转我们就可以控制请求的幂等。 5、使用分布式锁机制 数据库悲观锁、乐观锁、redis、zookeeper等实现(分布式锁另外单独讨论)
2024最新激活全家桶教程,稳定运行到2099年,请移步至置顶文章:https://sigusoft.com/99576.html
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请联系我们举报,一经查实,本站将立刻删除。 文章由激活谷谷主-小谷整理,转载请注明出处:https://sigusoft.com/71937.html