稳定性三十六计-幂等设计

简介: 为什么要幂等世界上最遥远的距离是我终于鼓起勇气,对着马路对面的你大喊:“你愿意娶我吗?”我看到你面带灿烂的笑容,正回答的时候……一辆大卡车驶过,你的回答我没有听见。因各种不可抗因素产生的没有收到响应,一个简单有效的方法就是重试。被重试的接口必须是幂等的。幂等性是分布式系统设计中的一个重要概念,对超时处理、系统恢复等具有重要意义。

引子


群里发了一个总共1千元的拼手气红包,共10个。静儿点进去,额,抢到了0.05元。这个不甘心啊。退出来重新打开了这个红包,你猜怎样?显示我抢到了0.05元!


AO4H10KpI3u1AAAAABJRU5ErkJggg==.png


这就是幂等(idempotence),不管多少次请求某一个资源,对资源都具有相同的影响。幂等性是系统的接口对外一种承诺,承诺只要调用接口成功,外部多次调用对系统只产生一次副作用。

 

为什么要幂等


世界上最遥远的距离是我终于鼓起勇气,对着马路对面的你大喊:“你愿意娶我吗?”我看到你面带灿烂的笑容,正回答的时候……一辆大卡车驶过,你的回答我没有听见。


因各种不可抗因素产生的没有收到响应,一个简单有效的方法就是重试。被重试的接口必须是幂等的。


幂等性是分布式系统设计中的一个重要概念,对超时处理、系统恢复等具有重要意义。

 

保证幂等的手段


保证幂等需要理清楚两件事情:幂等条件和期望结果。


大家可能听说过保证幂等的手段有token令牌、分布式锁、去重表、数据库唯一索引等。这些所谓的幂等手段实际上防重手段。防重本质是防止一个相同的请求被当成多个不同的请求来处理。幂等的条件是知道这是一个相同的请求。防重和幂等本质上是两个不同的阶段。

 

状态机幂等


在支付场景中,创建了一个支付订单,发起了一个支付请求,这个订单不论多少次重复请求,都应该保证最多只扣款一次。即


相同支付订单ID(幂等条件) —> 最多一次扣款(期望结果)


为了实现这个目标,可以考虑使用有限状态机。


有限状态机(Finite-state machine FSM),又称有限状态自动机,简称状态机,是表示有限个状态以及在这些状态之间的转移和动作等行为的数学模型。用于处理复杂的状态转换。


在这个支付的例子中,为了化简,不考虑退款、取消订单等复杂的状态,只考虑未支付和已支付两种状态之间的转换。


D067NpZak1c8AAAAAElFTkSuQmCC.png


由上面的状态转换图可以看到,相同支付订单ID从未支付状态,要不就是支付不成功停留在未支付状态,要不就是支付成功,状态转移为已支付。此状态转移过程不可逆。

 

public enum OrderStateEnum {
    UNPAID {
        @Override
        public OrderStateEnum changeState() {
            if (doPay()) {
                return PAID;
            }
            return UNPAID;
        }
    },
    PAID {
        @Override
        public OrderStateEnum changeState() {
            return PAID;
        }
    };
    public abstract OrderStateEnum changeState();
    public boolean doPay() {
        //这里是逻辑伪代码,可以是发起下游调用请求支付通道等
        return true;
    }
}


这是一个java版本的简单状态机实现。状态机里定义了一个未支付状态和其行为changeState。changeState又定义了一个未支付状态和其行为changeState。


利用状态机来实现这个幂等支付请求的设计流程图如下:


QPUmQAAAABJRU5ErkJggg==.png


参考状态机实现和上图可知,相同支付ID的请求,支付状态只能进行一次从未支付到已支付的转换。从而保证了其幂等性。

 

按目标幂等


先来回答一个小学生的问题:


定了一个会议,参加人数为10人。发现会议室的椅子只有5把。3个提前来到会议室的同学热心的去其他地方搬椅子进来。问:每人要搬几把椅子?


有人要说这不是把简单的问题复杂了吗?大家看到椅子不够就去搬,看够10把椅子了就不搬就可以了。对了,这其实是一个很好的解题思路,完全可以用在设计当中,就是按目标幂等。


相同会议ID(幂等条件) —> 总数10把椅子(期望结果)


利用按目标幂等来实现这个总数10把椅子请求的设计流程图如下:


+MhZs8eAx0QAAAABJRU5ErkJggg==.png


参考状态机实现和上图可知,相同支付ID的请求,支付状态只能进行一次从未支付到已支付的转换。从而保证了其幂等性。

 

总结


支持幂等是一个接口的基本素养



目录
打赏
0
0
0
1
2
分享
相关文章
秒杀场景下如何保证数据一致性?就这个问题我给出了最详细的方案
本文主要讨论秒杀场景的解决方案。 什么是秒杀? 从字面意思理解,所谓秒杀,就是在极短时间内,大量的请求涌入,处理不当时容易出现服务崩溃或数据不一致等问题的高并发场景。 常见的秒杀场景有淘宝双十一、网约车司机抢单、12306抢票等等。
秒杀系统优化:用解耦提升系统性能的秘诀!
大家好,我是小米,一个热爱分享技术经验的29岁程序员。本文主要探讨了解耦的概念及其在秒杀系统中的应用,特别是如何通过解耦提升系统的扩展性和容错能力。文中对比了HTTP/RPC同步调用和消息队列两种方式,分析了各自的优缺点及适用场景,帮助大家更好地选择合适的解耦方案。希望本文能让大家对解耦有更深入的理解。
106 8
秒杀系统优化:用解耦提升系统性能的秘诀!
产品迭代过程中如何保证产品质量的稳定性
产品迭代过程中如何保证产品质量的稳定性
思考:如何保证服务稳定性?
只有每个业务环节都稳如泰山,才可以保障整个稳定性。单服务的稳定可以从以下几个方面来进行:
多版本并行,测试如何做好质量保障?
第一个是成本问题,单独搭建一套可用的测试环境,包括云服务器、缓存、消息队列和数据库,成本是很高的;
多版本并行,测试如何做好质量保障?
没有10年的功力,根本不可能设计出这么好的高并发限流方案!
没有10年的功力,根本不可能设计出这么好的高并发限流方案!
并发-分布式锁质量保障
并发问题是电商系统最常见的问题之一,例如库存超卖、抽奖多发、券多发放、积分多发少发等场景;之所以会出现上述问题,是因为存在多机器多请求同时对同一个共享资源进行修改,如果不加以限制,将导致数据错乱和数据不一致性;解决并发问题的方式有很多,例如:队列、异步、响应式、锁都可以;由于当前互联网都是分布式系统,因此本文只针对使用较为广泛的分布式锁的方式来进行叙述如何进行质量保障
并发-分布式锁质量保障总结
并发问题是电商系统最常见的问题之一,例如库存超卖、抽奖多发、券多发放、积分多发少发等场景;之所以会出现上述问题,是因为存在多机器多请求同时对同一个共享资源进行修改,如果不加以限制,将导致数据错乱和数据不一致性;解决并发问题的方式有很多,例如:队列、异步、响应式、锁都可以;由于当前互联网都是分布式系统,因此本文只针对使用较为广泛的分布式锁的方式来进行叙述如何进行质量保障。
并发-分布式锁质量保障总结
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等