一：什么是幂等性：

• 1：方法调用一次和调用多次得到的结果是一样的，则称为方法是幂等的。

• 2：HTTP幂等性：资源请求一次，或者多次产生的副作用是相同的。

  • 例如： 我们发送1次get请求，获取一个ok，与发送100次请求，获取这个ok，效果是一样的，都是得到一个ok，中间没有给服务器带来任何压力，也没有修改数据库，因此我们称这个get请求是幂等的。（不是强调结果是否相同，而是副作用是否相同）

• 3：HTTP中的请求是不是幂等的呢？

  • GET获取请求， 是幂等的。
    • 请求一次，与请求多次，不会对后端造成任何影响。
  • DELECT删除请求， 是幂等的。
    • 删除一次，与删除多次，结果都是被删除了。
  • POST请求创建资源，不是幂等的。
    • 两次创建操作，会对在后台创建两个不同的资源，因此不是幂等的。
  • PUT请求更新资源， 是幂等的。
    • 更新一次，与更新多次（数据相同）， 得到的结果都是被更新后的。

• 4： 应用角度----幂等性场景：

  • 1：因为网络波动，引起重复请求。
    • 案例：例如收藏（取消收藏）请求，我们请求了一次，因为网络原因，我们一直没有返回响应，用户由于没有看到被收藏了，结果再次点击收藏，而两次点击收藏导致我们后端仍处于未收藏状态，影响了幂等性。
  • 2： 用户重复操作，导致重复扣款，重复下单等问题。
    • 例如： 双十一，用户下单请求，提交一次后，由于网络堵塞，用户点击了刷新，导致相同订单重复请求，则会导致数据库中存在两个订单。
  • 3：应用中使用了超时，重试机制。
    • Nginx重试， RPC框架重试， 业务层面重试等。
  • 4：第三方平台接口（支付宝），异步回调。
    • 例如： 支付宝支付完成后，支付宝会调用我们后台接口，证明支付完成，但是，由于异常，支付宝调用了两次我们后台，则导致我们后台扣款了两次，实际支付宝只扣款一次。
  • 5： 页面刷新， 回退按钮，导致重复提交表单。
    • 例如：学校网站问卷调查统计，再提交时，由于网络延时，或者后端反应过慢，导致用户重新刷新，重新提交表单，则导致问卷多出一份。
  • 6：定时任务导致重复执行。
  • 7： 多核浏览器问题：
    • 某些版本的浏览器，请求一次，发送两次请求。

二：数据访问的幂等性：

• 幂等性设计的地点：由于都是对于数据库数据进行操作，才设计幂等性，因此我们要在访问数据库之前做幂等性设计。
• 读请求，显然不需要设计幂等性。
• 写请求，增删改需要设计幂等性。

2.1：增加操作：

• insert操作： 例如： insert into student(id, name, age, sex);
  • 如果是自增主键，则会出现幂等性问题，因为两次都可以插入。
  • 如果给 name, age, sex,设置唯一索引，则不会出现幂等性问题， 因为数据库会报错。

2.2：删除操作：

• delect 操作：
  • 相对删除：删除前20条数据， 会出现幂等问题。
  • 绝对删除：删除id是1的数据， 不会出现幂等问题。

2.3：更新操作：

• 相对更新：将id为1的价格增加100， 此时不是幂等的。
• 绝对更新：将id为1的价格修改成100， 此时是幂等的。

三：幂等性的解决方案：

3.1：前端幂等性的实现：

• 1：按钮设置成只能操作一次， 防止用户重复提交。

  • 例如提交按钮，点击后，前端变成灰色，不能再次点击了。

• 2： tocken机制， 防止重复提交。：

  • 例如: 当请求某个页面的时候，我们后端生成一个token，将这个token存放在页面中一起返回给前端， 前端进行提交时，携带上页面中的token，后端取出前端携带的token和后端保存的token，两个进行比较，如果token一致，则表示第一次提交，则删除后端的token。如果发现前端携带的token，我们后端不存在，则表示不是第一次提交，则返回响应，重复提交。

• 3: Post/Redirect/Get（PRG）模式：

  • 例如： 前端当用户提交后，立刻发出一个请求，请求发送成功的页面。这样避免用户刷新页面导致重复提交，也不会出现浏览器提示重复提交的警告，而且也消除了因为前进和后退导致重复提交的问题。

• 4：在Session中存在特殊标志：

  • 案例： 与token机制相同， 我们可以在服务端生成一个唯一标识，将他存入到session中，将session中的唯一标识也写入到隐藏表单中，将表单返回给客户端。客户端提交信息时，后端根据session_id拿到session信息，与表单中的session信息比对，如果相同则删除服务端中的session中的唯一标识，如果找不到，说明不是第一次提交则返回重复提交。

3.2： 后端幂等性的实现：

• 1： 使用唯一索引防止幂等性问题：

  • 建立唯一索引后，插入数据如果出现重复的，则会抛出异常，因此可以防止幂等性。

• 2：ToKen + Redis幂等性方案：

• 3：状态机幂等：

  • 针对某些更新操作， 比如业务中需要修改订单状态：待支付状态， 支付中， 支付成功， 支付失败，订单超时等。
  • 在进行接口的设计时，我们最好只支持状态的单向改变，例如更新成 status = 1;这样即使多次，状态也不会改变。

• 4：乐观锁实现幂等：

  • 先查询出被更新的信息，得到版本version = 1
  • 通过版本号进行更新，如果版本号匹配，说明之前没有改变，则进行更新，如果版本号不匹配则说明已经操作过了，无需再进行操作。

• 5：防重表实现幂等性：

• 我们要增加一个表，这个表叫做防重表。这个防重表中有一个字段，这个字段是一个唯一索引。案例我们下订单，我们每次下一个订单，就向防重表中增加一个数据，如果订单id重复了，则表示第二次加入这个订单，则返回重复提交。

• 6: select + insert方案：

  • 在进行插入操作之前先查询一下是否改变了，这种方案单机条件可以，但是分布式下不可以。

• 7： 分布式锁方案：

  • 尝试获取分布式锁，如果获取到了，则进行业务逻辑，如果没有获取到，则返回请稍后再试。

• 8： 缓冲队列解决幂等性：

  • 我们后端将所有的请求都保存到缓冲队列中， 然后使用异步任务处理里面的请求，异步任务中过滤掉重复的请求。

• 9：全局唯一号实现幂等：

  • 在执行操作前先根据这个全局唯一ID是否存在，来判断这个操作是否已经执行。如果不存在则把全局ID，存储到存储系统中，比如redis，并设置有效期。如果存在则表示该方法已经执行。