44 | 弹力设计:幂等性设计
该思维导图由 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-11623 - 心宿二这篇文章ID生成的讲解,解开了我一个长久的疑问,就这一段,付费199我也是愿意的。
作者回复: 谢谢
2018-04-1327 - 酱了个油皓哥,由客户端如何生存唯一id呀,感觉twitter的算法适合服务器,有1024个服务器限制,可以给点提示吗
作者回复: 你什么集群?1024个不够?如果实在不够加几个bit给机器id吧
2018-03-2536 - MC问题:上游(upstream)和下游(downstream)两个词是不是用反了?如果不是,这两个术语的在这篇文章上下文中的具体意思是什么?
作者回复: 有可能是我用错了。我的“上游”偏请求方,“下游”偏响应方。
2018-03-1386 - 一黑到底请问一下,第一次请求因超时失败了,然后再次请求,怎么做到全局id是一样的?因为两次请求的时间点变化了。
作者回复: 重试的时候不用重新获取新的id,用上次的就好了。
2018-05-1454 - fishcat一次和多次请求某一个资源应该具有同样的副作用 这里说的副作用是什么意思?
作者回复: 所谓副作用,就是对这个资源 的变更所带来的连锁反应和影响。
2018-03-033 - thomas你这里说的副作用是指什么?
作者回复: 你问的是哪句话的“副作用”?
2018-03-0221 - 颇忒妥使用snowflake 的话要配置machine id ,那如果用auto scale 的时候怎么自动配置呢?
作者回复: 一方面,你需要一个控制系统(这个系统是跑不掉的(想想CMDB),可以由它来分配),另一方面,可以用一些机器标识,如Mac地址,lP地址什么的。
2018-06-09 - Alan处理流程那节我觉得有问题,首先你插曲如果存在报错,只能说明你收到了,并不能说明处理成功了,那如果出现存在,但是处理未成功,返回丢失了,你下次重试的时候怎么判断状态呢
作者回复: 有点没看懂
2018-03-162 - whhbbq抱歉,我理解有误。我们的做法是相当于在上游防止重复提交。
作者回复: 上游防重,那需要在请求超时后做查询了。文章中也讲了这种情况
2018-03-03