95 | 项目实战二:设计实现一个通用的接口幂等框架(实现)
王争
该思维导图由 AI 生成,仅供参考
上一节课,我们讲解了幂等框架的设计思路。在正常情况下,幂等框架的处理流程是比较简单的。调用方生成幂等号,传递给实现方,实现方记录幂等号或者用幂等号判重。但是,幂等框架要处理的异常情况很多,这也是设计的复杂之处和难点之处。比如,代码运行异常、业务系统宕机、幂等框架异常。
虽然幂等框架要处理的异常很多,但考虑到开发成本以及简单易用性,我们对某些异常的处理在工程上做了妥协,交由业务系统或者人工介入处理。这样就大大简化了幂等框架开发的复杂度和难度。
今天,我们针对幂等框架的设计思路,讲解如何编码实现。跟限流框架的讲解相同,对于幂等框架,我们也会还原它的整个开发过程,从 V1 版本需求、最小原型代码讲起,然后讲解如何 review 代码发现问题、重构代码解决问题,最终得到一份易读、易扩展、易维护、灵活、可测试的高质量代码实现。
话不多说,让我们正式开始今天的学习吧!
V1 版本功能需求
上一节课给出的设计思路比较零散,重点还是在讲设计的缘由,为什么要这么设计。今天,我们再重新整理一下,经过上一节课的分析梳理最终得到的设计思路。虽然上一节课的分析很复杂、很烧脑,但思从深而行从简,最终得到的幂等框架的设计思路是很简单的,主要包含下面这样两个主要的功能开发点:
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
设计和实现通用的接口幂等框架是本文的核心内容。文章首先介绍了幂等框架的设计思路和异常处理流程,讨论了幂等号的生成方式,并选择了由调用方自行生成的实现方式。此外,文章还详细介绍了幂等号的存储、查询和删除的实现思路,以及使用Redis作为键值数据库的原因。在最小原型代码实现部分,文章给出了一个简单的Idempotence类的代码实现,展示了如何使用不到30行代码实现一个幂等框架。接着,文章对MVP代码进行了重构,解决了代码可读性、可扩展性、可测试性和灵活性等方面的问题。重构后的代码结构更加清晰,将幂等号的读写独立出来,设计成了IdempotenceStorage接口和RedisClusterIdempotenceStorage实现类。同时,幂等号生成算法也被抽离出来,放到了IdempotenceIdGenerator类中。这样的设计使得代码更易于扩展和维护。总的来说,本文通过简洁清晰的语言,深入浅出地介绍了幂等框架的设计思路和代码实现,为读者提供了一份易读、易扩展、易维护、灵活、可测试的高质量代码实现。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《设计模式之美》,新⼈⾸单¥98
《设计模式之美》,新⼈⾸单¥98
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(35)
- 最新
- 精选
- 高源老师讲的真的好后期老师把所讲课程配套代码提供上,我对着再仔细阅读一次结合实际应用到实际开发中,谢谢
作者回复: 可以的,我现在有空了,我最近就能补上,关注我的github吧: https://github.com/wangzheng0822
2020-06-10312 - JasonRedisClusterIdempotenceStorage是不是少implements IdempotenceStorage?
作者回复: 嗯嗯 多谢指出~
2020-06-109 - cricket1981有一点不明白,框架为什么要对外提供delete接口呢?调用方乱用怎么办?如果是为了处理系统异常,我觉得可以让调用方重新生成新的幂等号再发起请求,而不是依赖调用方在重试之前正确地调用delete接口。
作者回复: 不是重试之前删除,而是在出错之后删除。重试的时候并不知道原来是执行正确还是错误、
2020-06-263 - 北纬8℃老师,能帮菜鸟讲解下幂等咋就实现了,区分请求,是一个新的请求或者是同一个请求再次发送
作者回复: 幂等号相同就是同一个请求。两个请求是否是同一个请求,由业务发起方来定义(他说了算),他觉得某两个请求是同一个请求,就赐予相同的幂等号。
2020-07-0881 - 小晏子delete是否返回boolean和如果出错该如何处理这个问题,要看业务方是处理业务和幂等号的顺序,如果先存储幂等号,在做业务,那么业务没处理成功时,后续处理就要删除幂等号,然后重复业务处理,这就要保证删除幂等号一定要成功,这样就要返回boolean值;相反,如果业务处理成功后在保存幂等号,那么删除幂等号成功与否都无关,删除幂等号可以不反回值。 幂等号生成算法没必要再开个接口,因为幂等号生成算法需要稳定性全局性,否则不同业务用不同算法生成幂等号,那么幂等框架就可能无法区分不同的业务请求了。 后续版本可以让幂等框架更易用,不需要过多配置,比如提供一个注解,使用方直接在需要幂等的接口上添加上这个注解,那么这个请求就一定会保证幂等。2020-06-10638
- Jxin1.针对mvp代码,delete不该返回boolean,void即可。因为该方法只有在技术异常(网络超时,redis节点无法提供服务)时才会有失败的场景。而我的习惯,是把技术异常放在最外层处理,或则代理层处理(技术异常的处理应该尽量与业务代码分离)。如果delete里面也有业务逻辑,比如入参检验,那么我会返回boolean。因为这时候的异常是业务代码该处理的场景,同时我认为调用方无需知道delete因何失败,只需要知道delete失败,所以收敛delete内部业务异常,对外只以boolean返回值做交互。 2.因为唯一id的需求方并不只有幂等框架,抽离出来在其他场景也能用,比如流水id。我认为幂等服务方提供幂等id生成接口给调用方的方式并不合适。这样做是一种资源的浪费。在这个场景,我只是为了保证幂等id生成代码的去重,并没有动态上扩缩节点调整负载的诉求。所以幂等id生成代码以公共包的方式被调用方项目依赖,仅做代码级的复用会好些。 3.抽成公共包(去重),提供声明式接口(易用),提供配置接口(灵活)。2020-06-1019
- 88591能沉下心来把细节都做好那才是真的牛!2020-07-168
- Jemmy优化:IdempotenceIdGenerator 可以面向接口编程,未来 uuid 生成方式可能会变。2020-06-144
- Jackeydelete还是返回boolean好一点,对删除出错的key可以人工干预或者记录下来统一处理2020-06-104
- lengrongfu作为框架功能,应该要把异常上抛给调用方,让调用方自己决定如何处理;现在通用的功能框架几乎都是这么做的。2020-08-063
收起评论