关于幂等介绍

@[TOC]标题

# 目录

## 二级目录

### 三级目录

什么是幂等？

 定义：同一个数据操作，因为各种可能的失误或者系统异常，而导致不可避免的被执行了多次，但是其执行结果跟只操作一次得到的结果完全相同。

为什么要使用幂等？

在一个规范的大数据系统中，对一个业务模块的数据处理，一定会经过一条完整的数据处理链路，数据接入-数据源落地-数据计算-结果存储。我们更加关注的是数据的业务结果，是否能够做到真正的准确（幂等）。也就是最终结果既不能丢失，也不要重复。这个可以通过表设计和最终的结果写入程序优化来实现。而数据处理的中间各个环节，不可能也没有必要做到完全的严格幂等性。我们只需要在最大程度上保证数据不丢失就可以，至于数据是否重复发送和重复消费，没有必要过于关心，因为少许的过程数据重复，对于整个系统来说丝毫不受影响。对于一个大数据系统而言，实现幂等性是一个系统性工程，是一种架构设计思想，绝对不是单一的一个配置。

使用幂等的场景有哪些？

• 前端重复提交

用户在新增页面上快速点击多次,造成发了多次请求，后端重复保存了多条一模一样的数据。如用户提交订单,生成很多重复的订单。

• 消息重复消费

消息重复消费，一般指的是消息中间件，如RabbitMQ, 由于网络抖动，MQ Broker将消息发送给消费端消费，消费端进行了消费，在返回ack给MQ Broker时网络中断等原因，导致MQ Broker认为消费端没能正常消费消息，这时候MQ Broker会重复将这条消息发给消费端进行消费，如果没有做幂等，就会造成客户端重复消费同一条消息。

• 页面回退再次提交

举个例子，用户购买商品的时候，如果第一次点击下单按钮后，提示下单成功，跳转到下单成功页面，这时候如果用户点击浏览器返回按钮，返回上一个下单页面，重新点击下单按钮，这时候如果没有做幂等的话，也会造成重复下单的问题。

• 微服务互相调用

分布式系统中，服务之间的通信一般都通过RPC或者 Feign进行调用，难免网络会出小问题，导致此次请求失败，这时候这些远程调用，如feign都会触发重试机制,所以我们也需要保证接口幂等。

1. 用户的重复提交或用户的恶意攻击后，后端收到好几次请求。
2. 分布式系统中调用接口，有可能会因为网络原因而调用失败，一般在设计的时候会
   对接口调用加上失败重试的机制。

幂等设计方案有哪些？

后端处理：

• select + insert+主键/唯一索引冲突
• 直接insert +主键/唯一索引冲突
• 状态机幂等
• 抽取防重表
• 幂等处理的八种方案
• token令牌：

首先客户端请求token接口，获取到token

服务端生成token并在redis中存一份

每次请求的时候，客户端将token带过来，由拦截器检验token

token存在redis中则说明是第一次请求， 完成数据处理，并删除redis中的token

第二次客户端再携带token时，去redis中查，如果redis中没有，那么说明是第二次请求了，返回重复操作提示。

• 悲观锁(如select for update)
• 乐观锁
• 分布式锁

如何进行测试？

可以通过压测，不断向服务器请求接口。