设计模式之美
王争
前 Google 工程师,《数据结构与算法之美》专栏作者
123426 人已学习
新⼈⾸单¥98
登录后,你可以任选6讲全文学习
课程目录
已完结/共 113 讲
设计模式与范式:行为型 (18讲)
设计模式之美
15
15
1.0x
00:00/00:00
登录|注册

95 | 项目实战二:设计实现一个通用的接口幂等框架(实现)

存储、查询、删除幂等号的功能
生成幂等号的功能
异常处理
幂等框架处理流程
课堂讨论
重点回顾
重构最小原型代码
Review最小原型代码
最小原型代码实现
V1版本功能需求
设计思路
实现篇:设计实现一个通用的接口幂等框架

该思维导图由 AI 生成,仅供参考

上一节课,我们讲解了幂等框架的设计思路。在正常情况下,幂等框架的处理流程是比较简单的。调用方生成幂等号,传递给实现方,实现方记录幂等号或者用幂等号判重。但是,幂等框架要处理的异常情况很多,这也是设计的复杂之处和难点之处。比如,代码运行异常、业务系统宕机、幂等框架异常。
虽然幂等框架要处理的异常很多,但考虑到开发成本以及简单易用性,我们对某些异常的处理在工程上做了妥协,交由业务系统或者人工介入处理。这样就大大简化了幂等框架开发的复杂度和难度。
今天,我们针对幂等框架的设计思路,讲解如何编码实现。跟限流框架的讲解相同,对于幂等框架,我们也会还原它的整个开发过程,从 V1 版本需求、最小原型代码讲起,然后讲解如何 review 代码发现问题、重构代码解决问题,最终得到一份易读、易扩展、易维护、灵活、可测试的高质量代码实现。
话不多说,让我们正式开始今天的学习吧!

V1 版本功能需求

上一节课给出的设计思路比较零散,重点还是在讲设计的缘由,为什么要这么设计。今天,我们再重新整理一下,经过上一节课的分析梳理最终得到的设计思路。虽然上一节课的分析很复杂、很烧脑,但思从深而行从简,最终得到的幂等框架的设计思路是很简单的,主要包含下面这样两个主要的功能开发点:
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

设计和实现通用的接口幂等框架是本文的核心内容。文章首先介绍了幂等框架的设计思路和异常处理流程,讨论了幂等号的生成方式,并选择了由调用方自行生成的实现方式。此外,文章还详细介绍了幂等号的存储、查询和删除的实现思路,以及使用Redis作为键值数据库的原因。在最小原型代码实现部分,文章给出了一个简单的Idempotence类的代码实现,展示了如何使用不到30行代码实现一个幂等框架。接着,文章对MVP代码进行了重构,解决了代码可读性、可扩展性、可测试性和灵活性等方面的问题。重构后的代码结构更加清晰,将幂等号的读写独立出来,设计成了IdempotenceStorage接口和RedisClusterIdempotenceStorage实现类。同时,幂等号生成算法也被抽离出来,放到了IdempotenceIdGenerator类中。这样的设计使得代码更易于扩展和维护。总的来说,本文通过简洁清晰的语言,深入浅出地介绍了幂等框架的设计思路和代码实现,为读者提供了一份易读、易扩展、易维护、灵活、可测试的高质量代码实现。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《设计模式之美》
新⼈⾸单¥98
立即购买
登录 后留言

全部留言(35)

  • 最新
  • 精选
  • 高源
    老师讲的真的好后期老师把所讲课程配套代码提供上,我对着再仔细阅读一次结合实际应用到实际开发中,谢谢

    作者回复: 可以的,我现在有空了,我最近就能补上,关注我的github吧: https://github.com/wangzheng0822

    2020-06-10
    3
    12
  • Jason
    RedisClusterIdempotenceStorage是不是少implements IdempotenceStorage?

    作者回复: 嗯嗯 多谢指出~

    2020-06-10
    9
  • cricket1981
    有一点不明白,框架为什么要对外提供delete接口呢?调用方乱用怎么办?如果是为了处理系统异常,我觉得可以让调用方重新生成新的幂等号再发起请求,而不是依赖调用方在重试之前正确地调用delete接口。

    作者回复: 不是重试之前删除,而是在出错之后删除。重试的时候并不知道原来是执行正确还是错误、

    2020-06-26
    3
  • 北纬8℃
    老师,能帮菜鸟讲解下幂等咋就实现了,区分请求,是一个新的请求或者是同一个请求再次发送

    作者回复: 幂等号相同就是同一个请求。两个请求是否是同一个请求,由业务发起方来定义(他说了算),他觉得某两个请求是同一个请求,就赐予相同的幂等号。

    2020-07-08
    8
    1
  • 小晏子
    delete是否返回boolean和如果出错该如何处理这个问题,要看业务方是处理业务和幂等号的顺序,如果先存储幂等号,在做业务,那么业务没处理成功时,后续处理就要删除幂等号,然后重复业务处理,这就要保证删除幂等号一定要成功,这样就要返回boolean值;相反,如果业务处理成功后在保存幂等号,那么删除幂等号成功与否都无关,删除幂等号可以不反回值。 幂等号生成算法没必要再开个接口,因为幂等号生成算法需要稳定性全局性,否则不同业务用不同算法生成幂等号,那么幂等框架就可能无法区分不同的业务请求了。 后续版本可以让幂等框架更易用,不需要过多配置,比如提供一个注解,使用方直接在需要幂等的接口上添加上这个注解,那么这个请求就一定会保证幂等。
    2020-06-10
    6
    38
  • Jxin
    1.针对mvp代码,delete不该返回boolean,void即可。因为该方法只有在技术异常(网络超时,redis节点无法提供服务)时才会有失败的场景。而我的习惯,是把技术异常放在最外层处理,或则代理层处理(技术异常的处理应该尽量与业务代码分离)。如果delete里面也有业务逻辑,比如入参检验,那么我会返回boolean。因为这时候的异常是业务代码该处理的场景,同时我认为调用方无需知道delete因何失败,只需要知道delete失败,所以收敛delete内部业务异常,对外只以boolean返回值做交互。 2.因为唯一id的需求方并不只有幂等框架,抽离出来在其他场景也能用,比如流水id。我认为幂等服务方提供幂等id生成接口给调用方的方式并不合适。这样做是一种资源的浪费。在这个场景,我只是为了保证幂等id生成代码的去重,并没有动态上扩缩节点调整负载的诉求。所以幂等id生成代码以公共包的方式被调用方项目依赖,仅做代码级的复用会好些。 3.抽成公共包(去重),提供声明式接口(易用),提供配置接口(灵活)。
    2020-06-10
    19
  • 88591
    能沉下心来把细节都做好那才是真的牛!
    2020-07-16
    8
  • Jemmy
    优化:IdempotenceIdGenerator 可以面向接口编程,未来 uuid 生成方式可能会变。
    2020-06-14
    4
  • Jackey
    delete还是返回boolean好一点,对删除出错的key可以人工干预或者记录下来统一处理
    2020-06-10
    4
  • lengrongfu
    作为框架功能,应该要把异常上抛给调用方,让调用方自己决定如何处理;现在通用的功能框架几乎都是这么做的。
    2020-08-06
    3
收起评论
显示
设置
留言
35
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部