浅谈接口幂等性

前言

幂等性，是开发人员在日常开发中必须要考虑的，尤其是转账、支付等涉及金额交易的场景，如果出现幂等性的问题，造成的后果是非常严重的。

本文将分享一下什么是幂等性以及如何保证幂等性。

什么是幂等性

幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。

在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。

幂等性产生原因

• 前端未做限制，导致用户重复提交

• 使用浏览器后退，或者按F5刷新，或者使用历史记录，重复提交表单

• 网络波动，引起重复请求

• 超时重试，引起接口重复调用

• 定时任务设置不合理，导致数据重复处理

• 使用消息队列时，消息重复消费

如何保证幂等性

1.前端处理

• 提交按钮点击置灰，或者增加loading

• 页面重定向（PRG），PRG模式即POST-REDIRECT-GET，当用户进行表单提交时，会重定向到另外一个提交成功页面，而不是停留在原先的表单页面。这样就避免了用户刷新导致重复提交。同时防止了通过浏览器按钮前进/后退导致表单重复提交。

2.先select后insert + 唯一索引冲突

在保存数据前，我们需要先select一下数据是否存在。如果数据已存在，则返回失败（具体操作视业务情况而定），如果数据不存在，则执行insert操作。

但在高并发的场景下，可能会出现两个请求select的时候，都没有查到数据，然后都执行了insert操作，所以此时会有重复数据产生，因此在数据库中，我们需要添加唯一索引来保证幂等。

流程图如下：

先查后插+唯一索引.png

此方案适用于新增操作的接口，如用户注册。

3.建去重表

某些业务场景，是允许重复数据存在的，仅在流程的某个环节才不允许出现重复数据，这种情况直接在表中添加唯一索引是不合适的，所以就需要创建一张去重表。

CREATE TABLE `table_name` (
  `id` bigint(15) NOT NULL AUTO_INCREMENT COMMENT '自增主键',
  `order_id` varchar(100) NOT NULL COMMENT '订单号',
  `create_time` datetime DEFAULT NULL COMMENT '创建时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `index_order_id` (`order_id`),
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='去重表';

流程图如下：

去重表.png

特别注意，防重表与业务表必须在同一数据库，并且操作要在同一事务中。

此方案适用于在业务中有唯一标识的插入场景中，比如在支付业务中，若一个订单只会支付一次，则订单ID可以作为唯一标识。

4.使用悲观锁

悲观锁，正如其名，具有强烈的独占和排他特性。它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。

在交易场景中，用户账户余额有100元，转出50元，正常情况下用户的余额剩余50元。

update account set amount-50 where id = 123;

如果此时有多个相同的请求，可能会导致用户的金额变为负数。所以此时可以使用悲观锁，将用户的行数据锁住，在同一时刻只允许一个请求获得锁，其他请求等待。

select * from account where id = 123 for update;

流程图如下：

悲观锁.png

需要特别注意的是：如果使用的是mysql数据库，存储引擎必须用innodb，因为它才支持事务。此外，这里id字段一定要是主键或者唯一索引，不然会锁住整张表。

因为悲观锁是需要在同一事务中锁住一行数据，所以如果事务比较长，会造成大量请求等待，影响接口性能。

5.使用乐观锁

乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号等于数据库表当前版本号，则予以更新，否则认为是过期数据。

乐观锁主要基于版本标识（version）进行操作，即每次操作查询数据时都要先查询出版本标识（version），然后根据版本标识（version）进行update操作。

select id,amount,version from account id = 123;

update account set amount=amount-50,version=version+1 where id=123 and version = 1;

当多个相同的请求查询信息时，版本标识是相同的，当其中一个请求完成update操作，后续请求影响条数均为0。

流程图如下：

乐观锁.png

6.根据状态机

很多时候，业务流程是有状态流转的，这个时候可以使用状态机来保证幂等性。

如订单业务中，存在状态「1-已下单，2-已支付，3-已完成，4-已取消」，按照业务流程，状态是依次流转的，所以在update操作时，我们就要根据本次的状态来更新下一次的状态。

update order_info set status = 3 where id = 123 and status = 2;

流程图如下：

状态机.png

7.使用分布式锁

分布式锁的逻辑是，每次请求都通过业务唯一ID来尝试获取锁，如果获取成功，就进行后续业务逻辑操作，如果获取失败，就舍弃请求直接返回。

分布式锁通常是基于redis来实现的。

流程图如下：

分布式锁.png

分布式锁是通过设置redis的过期时间来进行控制。如果过期时间设置太短，则无法有效防止重复请求；如果过期时间设置太长，则影响redis存储空间，甚至会影响后续业务操作。因此需要根据具体的业务情况，来设置合理的过期时间。

8.基于token机制

此方案包含两个请求阶段：

1.客户端请求服务端申请获取token

2.客户端携带token再次请求，服务端校验token后进行操作。

流程图如下：

token机制.png

这里有一个注意的点：

服务端验证token是否存在，要使用删除key的方式，即redis.del(key)，删除成功则表示校验token通过；

不能使用先查再删的操作，即先redis.get(key)，后redis.del(key)，这种方式在高并发下无法保证幂等。

---

参考资料

如何实现接口幂等性

高并发下如何保证接口的幂等性？