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