左耳听风
陈皓
网名“左耳朵耗子”,资深技术专家
180928 人已学习
新⼈⾸单¥98
登录后,你可以任选6讲全文学习
课程目录
已完结/共 119 讲
左耳听风
15
15
1.0x
00:00/00:00
登录|注册

44 | 弹力设计:幂等性设计

PRG模式
数据库排它限制
隐藏token
PUT方法
POST方法
DELETE方法
OPTIONS方法
HEAD方法
GET方法
使用关系型数据库或NoSQL构建存储系统
存储系统的关键性
查询已收到的交易
其他全局ID生成算法
Snowflake算法
在被调用的服务中实现幂等性
超时后查询调用结果
三种调用结果
幂等性的含义
性能设计篇
管理设计篇
弹力设计篇
幂等性接口的处理流程
HTTP的幂等性
处理流程
全局ID
解决方案
概念
分布式系统设计模式系列文章
幂等性设计

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

你好,我是陈皓,网名左耳朵耗子。
所谓幂等性设计,就是说,一次和多次请求某一个资源应该具有同样的副作用。用数学的语言来表达就是:f(x) = f(f(x))。
比如,求绝对值的函数,abs(x) = abs(abs(x))。
为什么我们需要这样的操作?说白了,就是在我们把系统解耦隔离后,服务间的调用可能会有三个状态,一个是成功(Success),一个是失败(Failed),一个是超时(Timeout)。前两者都是明确的状态,而超时则是完全不知道是什么状态。
比如,超时原因是网络传输丢包的问题,可能是请求时就没有请求到,也有可能是请求到了,返回结果时没有正常返回等等情况。于是我们完全不知道下游系统是否收到了请求,而收到了请求是否处理了,成功 / 失败的状态在返回时是否遇到了网络问题。总之,请求方完全不知道是怎么回事。
举几个例子:
订单创建接口,第一次调用超时了,然后调用方重试了一次。是否会多创建一笔订单?
订单创建时,我们需要去扣减库存,这时接口发生了超时,调用方重试了一次。是否会多扣一次库存?
当这笔订单开始支付,在支付请求发出之后,在服务端发生了扣钱操作,接口响应超时了,调用方重试了一次。是否会多扣一次钱?
因为系统超时,而调用方重试一下,会给我们的系统带来不一致的副作用。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

分布式系统设计模式中的弹力设计之幂等性设计是本文的核心内容。幂等性设计指的是一次和多次请求某一资源应该具有相同的副作用,而在分布式系统中,超时状态下的重试可能导致系统产生不一致的副作用。为解决这一问题,文章提出了两种处理方式:一是下游系统提供查询接口,上游系统在超时后查询状态;二是通过幂等性的方式,确保一次和多次请求结果一致。为实现幂等性,需要全局唯一ID来标识交易,可采用Snowflake等分布式ID生成算法。对于幂等性的处理流程,需要一个存储来记录已收到的交易,并在出现冲突时报错。此外,文章还介绍了HTTP方法的幂等性,如GET、HEAD、OPTIONS、DELETE和PUT等方法的特点和适用场景。对于POST方法,文章提出了防止多次提交的幂等性设计方案,包括在表单中隐藏token、数据库排它限制和采用PRG模式等。通过详细介绍幂等性设计的原理和实现方式,为分布式系统中的弹力设计提供了有益的参考。 总的来说,本文深入探讨了分布式系统中的弹力设计中的幂等性设计,强调了其重要性和实现方式。通过介绍全局唯一ID、HTTP方法的幂等性以及针对POST方法的幂等性设计方案,为读者提供了丰富的技术知识和实践经验。这些内容对于在分布式系统中设计弹性和可靠性的工程师和开发人员来说都具有重要的参考价值。

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

全部留言(63)

  • 最新
  • 精选
  • halfamonk
    私以为f(x) = f(f(x)) 这个数学公式表达幂等性不太对。因为f(f(x))应该是代表把f(x)的“结果”当作参数重新传入f()。这和文字的表述还是有区别的

    作者回复: 谢谢回复,我理解你的意思。不过数学上的幂等的确是这样描述的。参看:https://en.wikipedia.org/wiki/Idempotence

    2018-03-11
    6
    23
  • 心宿二
    这篇文章ID生成的讲解,解开了我一个长久的疑问,就这一段,付费199我也是愿意的。

    作者回复: 谢谢

    2018-04-13
    2
    7
  • 酱了个油
    皓哥,由客户端如何生存唯一id呀,感觉twitter的算法适合服务器,有1024个服务器限制,可以给点提示吗

    作者回复: 你什么集群?1024个不够?如果实在不够加几个bit给机器id吧

    2018-03-25
    3
    6
  • MC
    问题:上游(upstream)和下游(downstream)两个词是不是用反了?如果不是,这两个术语的在这篇文章上下文中的具体意思是什么?

    作者回复: 有可能是我用错了。我的“上游”偏请求方,“下游”偏响应方。

    2018-03-13
    8
    6
  • 一黑到底
    请问一下,第一次请求因超时失败了,然后再次请求,怎么做到全局id是一样的?因为两次请求的时间点变化了。

    作者回复: 重试的时候不用重新获取新的id,用上次的就好了。

    2018-05-14
    5
    4
  • fishcat
    一次和多次请求某一个资源应该具有同样的副作用 这里说的副作用是什么意思?

    作者回复: 所谓副作用,就是对这个资源 的变更所带来的连锁反应和影响。

    2018-03-03
    3
  • thomas
    你这里说的副作用是指什么?

    作者回复: 你问的是哪句话的“副作用”?

    2018-03-02
    2
    1
  • 颇忒妥
    使用snowflake 的话要配置machine id ,那如果用auto scale 的时候怎么自动配置呢?

    作者回复: 一方面,你需要一个控制系统(这个系统是跑不掉的(想想CMDB),可以由它来分配),另一方面,可以用一些机器标识,如Mac地址,lP地址什么的。

    2018-06-09
  • Alan
    处理流程那节我觉得有问题,首先你插曲如果存在报错,只能说明你收到了,并不能说明处理成功了,那如果出现存在,但是处理未成功,返回丢失了,你下次重试的时候怎么判断状态呢

    作者回复: 有点没看懂

    2018-03-16
    2
  • whhbbq
    抱歉,我理解有误。我们的做法是相当于在上游防止重复提交。

    作者回复: 上游防重,那需要在请求超时后做查询了。文章中也讲了这种情况

    2018-03-03
收起评论
显示
设置
留言
63
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部