左耳听风
陈皓
网名“左耳朵耗子”，资深技术专家，骨灰级程序员
立即订阅
40357 人已学习
课程目录
已完结 108 讲
0/6登录后，你可以任选6讲全文学习。
开篇词 | 洞悉技术的本质，享受科技的乐趣
免费
01 | 程序员如何用技术变现（上）
02 | 程序员如何用技术变现（下）
03 | Equifax信息泄露始末
04 | 从Equifax信息泄露看数据安全
05 | 何为技术领导力？
06 | 如何才能拥有技术领导力？
07 | 推荐阅读：每个程序员都该知道的知识
08 | Go语言，Docker和新技术
09 | 答疑解惑：渴望、热情和选择
10 | 如何成为一个大家愿意追随的Leader？
11 | 程序中的错误处理：错误返回码和异常捕捉
12 | 程序中的错误处理：异步编程以及我的最佳实践
13 | 魔数 0x5f3759df
14 | 推荐阅读：机器学习101
15 | 时间管理：同扭曲时间的事儿抗争
16 | 时间管理：如何利用好自己的时间？
17 | 故障处理最佳实践：应对故障
18 | 故障处理最佳实践：故障改进
19 | 答疑解惑：我们应该能够识别的表象和本质
20 | Git协同工作流，你该怎么选？
21 | 分布式系统架构的冰与火
22 | 从亚马逊的实践，谈分布式系统的难点
23 | 分布式系统的技术栈
24 | 分布式系统关键技术：全栈监控
25 | 分布式系统关键技术：服务调度
26 | 分布式系统关键技术：流量与数据调度
27 | 洞悉PaaS平台的本质
28 | 推荐阅读：分布式系统架构经典资料
29 | 推荐阅读：分布式数据调度相关论文
30 | 编程范式游记（1）- 起源
31 | 编程范式游记（2）- 泛型编程
32 | 编程范式游记（3） - 类型系统和泛型的本质
33 | 编程范式游记（4）- 函数式编程
34 | 编程范式游记（5）- 修饰器模式
35 | 编程范式游记（6）- 面向对象编程
36 | 编程范式游记（7）- 基于原型的编程范式
37 | 编程范式游记（8）- Go 语言的委托模式
38 | 编程范式游记（9）- 编程的本质
39 | 编程范式游记（10）- 逻辑编程范式
40 | 编程范式游记（11）- 程序世界里的编程范式
41 | 弹力设计篇之“认识故障和弹力设计”
42 | 弹力设计篇之“隔离设计”
43 | 弹力设计篇之“异步通讯设计”
44 | 弹力设计篇之“幂等性设计”
45 | 弹力设计篇之“服务的状态”
46 | 弹力设计篇之“补偿事务”
47 | 弹力设计篇之“重试设计”
48 | 弹力设计篇之“熔断设计”
49 | 弹力设计篇之“限流设计”
50 | 弹力设计篇之“降级设计”
51 | 弹力设计篇之“弹力设计总结”
52 | 管理设计篇之“分布式锁”
53 | 管理设计篇之“配置中心”
54 | 管理设计篇之“边车模式”
55 | 管理设计篇之“服务网格”
56 | 管理设计篇之“网关模式”
57 | 管理设计篇之“部署升级策略”
58 | 性能设计篇之“缓存”
59 | 性能设计篇之“异步处理”
60 | 性能设计篇之“数据库扩展”
61 | 性能设计篇之“秒杀”
62 | 性能设计篇之“边缘计算”
63 | 区块链技术的本质
64 | 区块链技术细节：哈希算法
65 | 区块链技术细节：加密和挖矿
66 | 区块链技术细节：去中心化的共识机制
67 | 区块链技术细节：智能合约
68 | 区块链技术 - 传统金融和虚拟货币
69 | 程序员练级攻略：开篇词
70 | 程序员练级攻略：零基础启蒙
71 | 程序员练级攻略：正式入门
72 | 程序员练级攻略：程序员修养
73 | 程序员练级攻略：编程语言
74 | 程序员练级攻略：理论学科
75 | 程序员练级攻略：系统知识
76 | 程序员练级攻略：软件设计
77 | 程序员练级攻略：Linux系统、内存和网络
78 | 程序员练级攻略：异步I/O模型和Lock-Free编程
79 | 程序员练级攻略：Java底层知识
80 | 程序员练级攻略：数据库
81 | 程序员练级攻略：分布式架构入门
82 | 程序员练级攻略：分布式架构经典图书和论文
83 | 程序员练级攻略：分布式架构工程设计
84 | 程序员练级攻略：微服务
85 | 程序员练级攻略：容器化和自动化运维
86 | 程序员练级攻略：机器学习和人工智能
87 | 程序员练级攻略：前端基础和底层原理
88 | 程序员练级攻略：前端性能优化和框架
89 | 程序员练级攻略：UI/UX设计
90 | 程序员练级攻略：技术资源集散地
91 | 程序员面试攻略：面试前的准备
92 | 程序员面试攻略：面试中的技巧
93 | 程序员面试攻略：面试风格
94 | 程序员面试攻略：实力才是王中王
95 | 高效学习：端正学习态度
96 | 高效学习：源头、原理和知识地图
97 | 高效学习：深度，归纳和坚持实践
98 | 高效学习：如何学习和阅读代码
99 | 高效学习：面对枯燥和量大的知识
左耳听风
登录|注册
44 | 弹力设计篇之“幂等性设计”
陈皓 2018-03-01
所谓幂等性设计，就是说，一次和多次请求某一个资源应该具有同样的副作用。用数学的语言来表达就是：f(x) = f(f(x))。
比如，求绝对值的函数，abs(x) = abs(abs(x))。
为什么我们需要这样的操作？说白了，就是在我们把系统解耦隔离后，服务间的调用可能会有三个状态，一个是成功（Success），一个是失败（Failed），一个是超时（Timeout）。前两者都是明确的状态，而超时则是完全不知道是什么状态。
比如，超时原因是网络传输丢包的问题，可能是请求时就没有请求到，也有可能是请求到了，返回结果时没有正常返回等等情况。于是我们完全不知道下游系统是否收到了请求，而收到了请求是否处理了，成功 / 失败的状态在返回时是否遇到了网络问题。总之，请求方完全不知道是怎么回事。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《左耳听风》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(40)
macworks等幂性讲的很清楚2018-03-01 9
halfamonk私以为f(x) = f(f(x)) 这个数学公式表达幂等性不太对。因为f(f(x))应该是代表把f(x)的“结果”当作参数重新传入f()。这和文字的表述还是有区别的作者回复: 谢谢回复，我理解你的意思。不过数学上的幂等的确是这样描述的。参看：https://en.wikipedia.org/wiki/Idempotence
2018-03-11 5
小倬没有理解，感觉应该用业务内容做id，比如参数，要不然下游超时，上游再次发送请求，生成的id是不同的2018-06-16 2 4
幻想皓哥，这个专题能顺便说下分布式锁吗？我最近刚用db实现一个分布式锁。感觉不太满意。能否大概介绍一下这个主题？2018-03-05 4
邓呵呵以前对重复提交总觉得应该放前端实现，原来后端处理就是幂等性，受教了2018-04-27 2
刘波3S这篇文章ID生成的讲解，解开了我一个长久的疑问，就这一段，付费199我也是愿意的。作者回复: 谢谢
2018-04-13 2
酱了个油皓哥，由客户端如何生存唯一id呀，感觉twitter的算法适合服务器，有1024个服务器限制，可以给点提示吗作者回复: 你什么集群？1024个不够？如果实在不够加几个bit给机器id吧
2018-03-25 2
AlphaZero问题：上游（upstream）和下游（downstream）两个词是不是用反了？如果不是，这两个术语的在这篇文章上下文中的具体意思是什么？作者回复: 有可能是我用错了。我的“上游”偏请求方，“下游”偏响应方。
2018-03-13 2
灯火可亲请问全局ID生成策略是什么了 怎么让下游系统判断发过来的请求是同一个请求了2019-04-01 1
陈杨皓哥，在保存的地方，假设db保存，一个表可以使用数据库唯一索引来报错，但是在分库分表后，数据库唯一索引就不能工作了，只有把同一个这样的请求路由到同一个库，才可以，但是这样可能跟分库分表的依据冲突，这样情况下怎么让他报错？2018-10-28 1
sonnyching我们现在的系统设计的时候都没考虑到这些😂比如做幂等性接口的时候，下游每次收到订单都先查询一次，的确有点慢了。果然需要学习的地方还有很多呀。付费学习是值得的。2018-05-09 1 1
YY重复交易过来后，返回上次交易信息，这个上次交易信息是不是需要存储起来，这个返回信息怎样存储比较好，是否有必要把所有的返回信息都存储起来2018-03-06 1 1
thomas你这里说的副作用是指什么？作者回复: 你问的是哪句话的“副作用”？
2018-03-02 1
特约嘉宾受教了，🙏2018-03-01 1
前面等你在超时处理上，第一种方式是使用查询，会有问题；假如你的请求已经成功被对方接收，只是对方还没来得及处理或正在处理中或处理失败对方补偿中，这时你查询得到状态和调用前是一样的，重试一次对方系统可能就会产生副作用，所以还是要用第二种让对方支持幂等安全点
原文：一种是需要下游系统提供相应的查询接口。上游系统在 timeout 后去查询一下。如果查到了，就表明已经做了，成功了就不用做了，失败了就走失败流程。2019-12-07
布小丫学编程1、HTTP请求端：用户提交表单时，生成唯一标识作为改次提交的表单id，然后后台保存该唯一标识到数据库。
2、消费MQ的幂等性：通过数据的insert..on duplicate或着update set status where status = xxx
3、采用分布式锁，对同一用户操作进行限制，比如同一时间不能同时调用下单接口。（但是这里有可能会导致前一个任务未处理完，redis已失效的问题）2019-08-31
edisonhuang分布式服务的设计应该满足幂等性，幂等性的含义是，一个调用被发送多次所产生的副作用和被发送一次所产生的副作用是一样的。
由于每次服务的调用有三种状态，成功失败或是超时，幂等性是要解决超时的问题，当某处调用超时，如何保证重复调用而逻辑不会出错2019-07-04
涛哥迷妹有几个问题想请教下：
1、幂等性中的 【副作用】 是否 可以理解成对 资源or数据状态的改变？
2、Snowflake 生成的全局id 放到被调用端生成 每次请求都会生成一个唯一的di, 但是 这东西没有业务含义 怎么能判断 调用端 的每次请求是否是唯一的？ 需要再定义一个全局的 业务key?
3、全局ID 中 分布式存储 服务比如redis 存储分布式全局id，然后每次请求时还是去查询有没有这个全局id没有才查询? 每次都去分布式存储中查询全局id是不是性能也会比较低？2019-06-21
靠人品去赢幂等性，例子举的例子很实际，扣库存同一订单多次的提交。之前只是想一下对应的办法，比如说设置按钮一段时间只能触发一次的，没有考虑过这些问题的特征共性以及解决方案思路以及那些需要注意。基本是发现一个相关异常就填一个坑。
幂等性，就是对同一资源一次和多次具有同样的副作用，类似于扣库存一次扣一次，重试多次同一订单也应该是同样的，毕竟是同一个订单同一个商品。2019-04-10 1
With Lin不错2019-03-28
收起评论