93 | 项目实战二:设计实现一个通用的接口幂等框架(分析)
王争
该思维导图由 AI 生成,仅供参考
上三节课,我带你分析、设计、实现了一个接口限流框架。在分析阶段,我们讲到需求分析的两大方面,功能性需求分析和非功能性需求分析。在设计阶段,我们讲了如何通过合理的设计,在实功能性需求的前提下,满足易用、易扩展、灵活、高性能、高容错等非功能性需求。在实现阶段,我们讲了如何利用设计思想、原则、模式、编码规范等,编写可读、可扩展等高质量的代码实现。
从今天开始,我们来实战一个新的项目,开发一个通用的接口幂等框架。跟限流框架一样,我们还是分为分析、设计、实现三个部分,对应三节课来讲解。
话不多说,让我们正式开始今天的学习吧!
需求场景
我们先来看下幂等框架的需求场景。
还记得之前讲到的限流框架的项目背景吗?为了复用代码,我们把通用的功能设计成了公共服务平台。公司内部的其他金融产品的后台系统,会调用公共服务平台的服务,不需要完全从零开始开发。公共服务平台提供的是 RESTful 接口。为了简化开发,调用方一般使用 Feign 框架(一个 HTTP 框架)来访问公共服务平台的接口。
调用方访问公共服务平台的接口,会有三种可能的结果:成功、失败和超时。前两种结果非常明确,调用方可以自己决定收到结果之后如何处理。结果为“成功”,万事大吉。结果为“失败”,一般情况下,调用方会将失败的结果,反馈给用户(移动端 App),让用户自行决定是否重试。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文介绍了如何设计实现一个通用的接口幂等框架。作者首先回顾了之前讲到的限流框架的项目背景,指出公司内部的其他金融产品的后台系统会调用公共服务平台的服务,而为了简化开发,调用方一般使用Feign框架来访问公共服务平台的接口。接着,文章详细分析了接口请求超时时的处理方式,特别是针对不同类型的接口操作,如查询、删除、更新和修改等,提出了相应的处理建议。作者还强调了对响应时间敏感的调用方和对响应时间不敏感的调用方在处理超时的不同方式。最后,作者提出了抽象出一套统一的幂等框架,简化幂等接口的开发,以解决超时重试这些非业务相关的逻辑。整篇文章通过实际的需求场景和具体的操作方式,为读者提供了设计实现通用接口幂等框架的思路和方法,对于需要处理接口幂等性的开发人员具有一定的指导意义。文章还介绍了幂等号的概念和功能性需求,以及框架的易用性、性能和容错性方面的需求。最后,文章提出了希望开发一套统一的幂等框架,脱离具体的业务,让程序员通过简单的配置和少量代码,就能将非幂等接口改造成幂等接口。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《设计模式之美》,新⼈⾸单¥98
《设计模式之美》,新⼈⾸单¥98
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(23)
- 最新
- 精选
- J.Smile“如果幂等号已经存在,说明业务已经执行或正在执行,则直接返回;如果幂等号不存在,说明业务没有执行过,则记录幂等号,继续执行业务“ ------------------------------------------------- 这个判断存在与否也要保证原子性
作者回复: 判断是否存在+业务执行 要保持原子
2020-06-05517 - 小喵喵1 如果存储幂等号的外部存储器里面的数据太多了,会影响查询性能,如何优化? 2 如果存储幂等挂掉了,幂等逻辑无法正常运行,那这个就相当于没有幂等了。这个时候咋搞呢?
作者回复: 1. 定期删一下很老的数据 2. 让接口报错,后面会讲到的
2020-06-05213 - skull幂等如果外部存储挂掉了,就不能让业务正常使用了吧,否则会出问题
作者回复: 是的,跟限流框架对异常的处理不同。后面两篇有解答。
2020-06-183 - Jxin1.当给代码分论别类习惯了。那业务代码和技术代码的耦合就挺扎眼,总想着分离,透明掉技术代码,保护业务代码的干净。 课后题 1.mq消费重试,网络丢包重试。。。 2.技术上的想不到。有重试的地方好像都要。 疑问 容错性这个有点不理解。限流这个不生效还好说。幂等功能不生效?刷数已经在路上。
作者回复: 哈哈,看后面的两篇文章,有解释的。
2020-06-051 - 美美分布式系统中,有一台机器挂了,请求会打到另一台机器上,这个时候,第二台机器不知道第一台是什么情况,第一台的日志,我认为也没有什么价值了,除非服务有状态,某一个请求一直只打到一台服务器上,但这个设计就很复杂了,老师有别的建议吗?
作者回复: 没看懂你说的第一台机的日志没有价值的意思呢?两台机器大部分都是独立执行任务的吧,日志本来就不需要互通的吧
2020-06-152 - aoe重试场景: 1. 微信发送消息失败,可以手动触发”重发“ 2. 网吧电脑卡顿、死机,可以重启 3. 拨打电话无人接听,请稍后再拨 4. 秒杀没有抢到,下一轮再接再厉 5. 游戏通关后升级难度从头开始 需要用到幂等设计场景: 1. 下单时不要出现重复订单 2. 提款时千万别出Bug 3. 火箭发射时,按下点火按钮,只能点火一次 4. 造小宝宝的时候,自然界超强幂等2020-09-11537
- cricket1981分布式事务需要用到幂等设计:at-least-once + 幂等 == exactly-once2020-06-2615
- 小晏子1. RocketMQ支持消息失败定时重试。 2. 用到幂等设计的还有:1)用户短时间内多次点击提交,2)第三方平台接口以为异常多次异步回调。2020-06-059
- ,偏个题,最近刚好在做硬件设备的断点重连,场景是这样的: 在现场有wifi,所有的物联网设备通过wifi连接,有的设备在不断的移动过程中,可能移动到wifi范围之外,这个时候就需要支持断点重连,在设备进入wifi范围时重新建立连接,为此,有以下几种方案: 1.提高wifi信号的强度,减少连接断掉的几率 2.当前使用tcp连接,将其修改为udp连接,通过服务不断地向设备发包/设备向服务发包来保证,此时不需要保持连接,做法相对简单 3.定时重连,通过定时任务,每隔一段时间就重新建立连接 方案1不靠谱,毕竟现场的环境相当大,无法保证wifi能覆盖到每一个角落,成本也高 方案2无法使用,通过观察设备厂家提供的sdk,发现只提供tcp连接的调用方式,因此该方案无效 方案3感觉上可行,但是如果设备正在进行业务处理时重连,则必然会有负面影响,业务上有延迟,连接也有可能迟迟建立不起来 在上述思考之后,感觉在失去连接时重新建立连接即可,于是通过学习厂家的sdk,发现确实有提供连接断开之后的回调,于是现在的做法像是方案3的升级版,每当连接断掉后就将其加入重连队列,定时轮询队列,建立连接,连接成功后从队列中弹出,不成功则在下一轮定时任务中处理 这一版本的断点重连稳定性很好,但是依旧存在问题,有人发现了吗?那么怎么解决这个问题呢?(提醒一下,迭代器)2020-06-107
- 麻薯不是年糕🍍我有个疑问。幂等号采用随机数生成,会不会这么个场景,比如下订单过程中由于网络波动,导致用户点了两次按钮 调用了两次接口,这种情况幂等号不是相当于生成两个不同的随机数吗?如果是这样,如果确保接口幂等性呢2021-11-163
收起评论