什么是接口幂等性？如何保证幂等性？用真实的场景说一下

蔚落 2023-10-11 01:29 57阅读 0赞

### 案例 ###

前段时间，我修改的一个功能涉及的接口，经过测试小姐姐的仔细盘查，出BUG了...而且是很严重的BUG。

![20201218100907242.png][]

可以看到同样的数据产生两条了，如果不注意，两条都审核通过...那就是白花花的银子，会被祭天的！

![20201218101038455.png][]

我一寻思，我也没改什么重要逻辑，就是加个字段，怎么就加出BUG了？？？

![我只是个无辜的靓仔(流泪熊猫头)\_靓仔\_熊猫\_无辜\_流泪\_只是表情][b70a2373d06b44ae27ba07ee928f23ca.gif]

然后我一顿常规操作，发现问题依旧存在...

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MzczNTMz_size_16_color_FFFFFF_t_70][]

嗯确认是BUG无疑了。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MzczNTMz_size_16_color_FFFFFF_t_70 1][]

经过我翻阅代码发现这个接口业务比较繁琐，调用链路有点长，所以处理需要一点时间，如果再加上前端没有做按钮限制，很容易就出现重复提交的情况。

正常逻辑是：申请退款->后端取可退金额->发起退款->提交->返回处理成功->关闭退款弹窗

网络慢和链路长：申请退款->后端取可退金额->发起退款->提交->提交->提交->提交->提交->提交->提交->提交->.....系统活过来了....返回处理成功->关闭弹窗

P0事故诞生...

![20201217171415398.png][]

### 解决 ###

最后，我在接口的方法中增加了幂等性的校验，采用的是分布式锁，限制同一条数据在短时间内不允许重复操作（对于数据不需要经常变动，适合这种方法）

//接口锁，不允许短时间操作过多
    String key = "CARD_REFUND_"+customerCardId;
    if (!redisUtils.getLock(key, 2000)) {
        throw new BusinessException("系统繁忙，稍后重试");
     }

### 什么是幂等性？ ###

> 根据百度百科的说明，总结起来就是：多次执行所产生的的影响与一次执行的影响相同。
> 
>  *  订单接口, 不能多次创建订单
>  *  支付接口, 重复支付同一笔订单只能扣一次钱
>  *  支付宝回调接口, 可能会多次回调, 必须处理重复回调
>  *  普通表单提交接口, 因为网络超时等原因多次点击提交, 只能成功一次  
>     等等...

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MzczNTMz_size_16_color_FFFFFF_t_70 2][]

### 幂等性有什么用？ ###

1.  **前端重复提交表单**：在填写一些表格时候，用户填写完成提交，很多时候会因网络波动没有及时对用户做出提交成功响应，致使用户认为没有成功提交，然后一直点提交按钮，这时就会发生重复提交表单请求。
2.  **用户恶意进行刷单**：例如在实现用户投票这种功能时，如果用户针对一个用户进行重复提交投票，这样会导致接口接收到用户重复提交的投票信息，这样会使投票结果与事实严重不符。
3.  **接口超时重复提交**：很多时候 HTTP 客户端工具都默认开启超时重试的机制，尤其是第三方调用接口时候，为了防止网络波动超时等造成的请求失败，都会添加重试机制，导致一个请求提交多次。
4.  **消息进行重复消费**：当使用 MQ 消息中间件时候，如果发生消息中间件出现错误未及时提交消费信息，导致发生重复消费。

> 我们接口调用时正常情况下不会重复提交，但是如果遇到以上问题，可能就会出现重复数据问题。

![所跌死提!(原来如此)\_跌死\_原来如此表情][c9347206e845267e9ab445aeda3cc949.gif]

### 如何实现幂等性？ ###

一、**数据库主键实现**，我们都知道主键有唯一约束性，比较适合我们"插入"时的幂等性，能够保证这张表中只能存在一条该主键的记录。（该主键并非自增主键，而是我们程序生成的，如：UUID）

二、**数据库乐观锁实现**，数据库乐观锁方案一般只能适用于修改系统中已有的数据操作，一般就是在数据表中多增加一个标识字段，标识当前数据的版本。在数据更新的时候版本验证，并进行相应的版本更新！

> 例：update table set price=price+100,version=version+1 where id = 1 and version=2;

三、**Token令牌实现**，针对我以上哪种重复点击按钮的情况，可以用此方法避免重复提交。

简单来说就是在我们调用购买接口的时候先调用一下生成全局唯一token，然后请求购买接口的时候就用这个token一起请求，后端对这个token进行校验，确定匹配就执行业务操作，如果是二次或者假的，肯定是不能执行业务操作的，从而避免了数据重复提交的问题。

四、**请求方生成唯一序列号实现**，所谓序列号就是每次调用接口的时候附带一个短时间内不会重复的ID，这个序列号规则随意，请求方生成即可。当我们第一次调用的时候把该序列号进行存入redis中并设置一个过期时间，然后执行业务代码。当同一个序列号再次请求接口的时候先去redis中校验该序列号是否已存在，存在则是重复提交，返回错误。

> 伪代码
> 
> 查询序列号是否在redis中？
> 
> 存在->返回错误
> 
> 不存在->保存该序列号，然后执行业务代码

五、**分布式锁实现**，和四差不多，只不过这个序列号并不是请求方生成，而是根据业务的主键或者唯一性由后端生成的。（我就是采用这种方式解决）

//接口锁，不允许短时间操作过多
    String key = "CARD_REFUND_"+customerCardId;
    if (!redisUtils.getLock(key, 2000)) {
        throw new BusinessException("系统繁忙，稍后重试");
    }
    
    
    //分布式锁的简单实现
    public boolean getLock(String key, long timeout) {
         if (redisTemplate.opsForValue().setIfAbsent(key, String.valueOf(timeout))) {
            Date date = DateUtils.getCurTimestamp();
            date.setTime(date.getTime() + timeout);
            redisTemplate.expireAt(key, date);
            return true;
          }
    
          return false;
     }

![以为不愿透露姓名的网友给你鼓掌，牛逼\_熊猫头\_牛逼\_鼓掌\_姓名\_网友\_不愿表情][7c9f4953e6791edf848f500ffef0c3f4.png]

### 总结 ###

幂等性在我们开发中是非常常见也非常重要的一个考虑点，尤其是商城订单、支付等与金钱相关的服务，毕竟安全性不做好，带来的是实际的钱财损失，丢饭碗事小。

> 还有其它更好的方案吗？欢迎留言探讨...

[20201218100907242.png]: https://img-blog.csdnimg.cn/20201218100907242.png
[20201218101038455.png]: https://img-blog.csdnimg.cn/20201218101038455.png
[b70a2373d06b44ae27ba07ee928f23ca.gif]: https://img-blog.csdnimg.cn/img_convert/b70a2373d06b44ae27ba07ee928f23ca.gif
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MzczNTMz_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20201218101302588.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MzczNTMz,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MzczNTMz_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20201218101506869.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MzczNTMz,size_16,color_FFFFFF,t_70
[20201217171415398.png]: https://img-blog.csdnimg.cn/20201217171415398.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MzczNTMz_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20201217170837319.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI0MzczNTMz,size_16,color_FFFFFF,t_70
[c9347206e845267e9ab445aeda3cc949.gif]: https://img-blog.csdnimg.cn/img_convert/c9347206e845267e9ab445aeda3cc949.gif
[7c9f4953e6791edf848f500ffef0c3f4.png]: https://img-blog.csdnimg.cn/img_convert/7c9f4953e6791edf848f500ffef0c3f4.png