# 幂等和防悬挂 ## 一、什么是幂等 先说结论,幂等就是让多次相同的请求有一致的结果。 我们做了一个幂等改造的需求,每次都会有人问我为什么要做这个,不用这个可以吗?我们想想看一个场景,我们购买一个ECS服务器,你购买之后商品系统就会发起一次交付,如果我们调用下游系统超时了(可能是因为**网络传输丢包**或者是**返回结果丢失**),这个时候我们是否能重试呢?重试是否会多交付一台实例给用户呢?  当前我们的系统都是采用了微服务架构,系统和系统之间通信的方式无非几种:① RPC ② MQ ③ HTTP,对于**远程调用**会有三种状态:成功,失败或者超时。前两者都是很明确的状态,而超时是一个**非常模糊**的状态。因此我们做好幂等可以保证我们发起交付,在超时重试的过程中能够保证交付,不会让我们因为重试而交付了多台机器造成资源浪费。对于**MQ**而言,幂等可以保证让我们避免重复消费。**HTTP**同理。 ## 二、怎么设计幂等? 我们的幂等解决方案是利用数据库的写完成的,也是比较粗线条的解决方案吧。我们设计了一个幂等表。 | 名称 | 类型 | 备注 | | ------- | ------ | ------------------------------------------ | | id | int64 | 主键 自增 | | key | string | 由幂等组和唯一标识的key,唯一索引 | | group | string | 幂等组 | | sigture | String | 方法签名,方法名和方法参数的md5值 唯一索引 | 当能够从幂等表中写入的时候就是写幂等成功,写入失败的时候判断是否是唯一索引冲突,是就是入幂等失败。所以幂等需要一个唯一标识来表示,这个唯一标识可以利用**雪花算法**生成。 一般的幂等过程是这样的:  ## 三、防悬挂和防悬挂的实现 防悬挂就是防止你撤销请求先至,创建请求后至,防止空回滚的策略。 他的大概过程是这样的: ### 1. 交付先至,撤销后至  ### 2. 撤销先至,交付后至  最后修改:2022 年 08 月 14 日 © 允许规范转载 打赏 赞赏作者 赞 2 如果觉得我的文章对你有用,请随意赞赏