【微服务】如何保证接口的幂等性

先理解什么是接口幂等性

接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。

举个最简单的例子，那就是支付，用户购买商品后支付，支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额返发现多扣钱了，流水记录也变成了两条，这就没有保证接口的幂等性。

哪些操作需要保证接口的幂等性

在增删改查4个操作中，尤为注意就是增加或者修改

新增操作

增加在重复提交的场景下会出现幂等性问题,如以上的支付问题

删除操作

删除一次和多次删除都是把数据删除。(注意可能返回结果不一样，删除的数据不存在，返回0，删除的数据多条，返回结果多个,在不考虑返回结果的情况下,删除操作也是具有幂等性的)

更新操作

修改在大多场景下结果一样,但是如果是增量修改是需要保证幂等性的,如下例子: 把表中id为XXX的记录的A字段值设置为1,这种操作不管执行多少次都是幂等的 把表中id为XXX的记录的A字段值增加1,这种操作就不是幂等的

查询操作

查询对于结果是不会有改变的，查询一次和查询多次，在数据不变的情况下，查询结果是一样的。select是天然的幂等操作

如何设计幂等性接口?

幂等意味着一条请求的唯一性。不管是你哪个方案去设计幂等，都需要一个全局唯一的ID，去标记这个请求是独一无二的。

• 如果你是利用唯一索引控制幂等，那唯一索引是唯一的

• 如果你是利用数据库主键控制幂等，那主键是唯一的

• 如果你是数据库锁（行级锁）的方式，底层标记还是全局唯一的ID

实现幂等性的常见方案

幂等性实现流程基本都是类似的，基于全局唯一ID实现

方案一：数据库唯一主键

数据库唯一主键的实现主要是利用数据库中主键唯一约束的特性，一般来说唯一主键比较适用于“插入”时的幂等性，其能保证一张表中只能存在一条带该唯一主键的记录。

使用数据库唯一主键完成幂等性时需要注意的是，该主键一般来说并不是使用数据库中自增主键，而是使用分布式 ID 充当主键，这样才能能保证在分布式环境下 ID 的全局唯一性。

流程如下

• ① 客户端调用服务端接口获取全局唯一ID，带着ID请求服务，在该次业务请求完成前，此ID不会重新获取。

• ② 服务端接收到请求后将该 ID 充当待插入数据的主键，然后执数据插入操作，运行对应的 SQL 语句。

• ③ 服务端将该条数据插入数据库中，如果插入成功则表示没有重复调用接口。如果抛出主键重复异常，则表示数据库中已经存在该条记录，返回错误信息到客户端，客户端可以重新请求。

• ④若返回成功则客户端跳转或刷新页面，直到进入下次业务流程才会获取新的全局唯一ID

方案二：数据库乐观锁

方案描述：

数据库乐观锁方案一般只能适用于执行“更新操作”的过程，我们可以提前在对应的数据表中多添加一个字段，充当当前数据的版本标识。这样每次对该数据库该表的这条数据执行更新时，都会将该版本标识作为一个条件，值为上次待更新数据中的版本标识的值。

例如，存在如下的数据表中：

为了每次执行更新时防止重复更新，确定更新的一定是要更新的内容，我们通常都会添加一个 version 字段记录当前的记录版本，这样在更新时候将该值带上，那么只要执行更新操作就能确定一定更新的是某个对应版本下的信息。

这样每次执行更新时候，都要指定要更新的版本号，如下操作就能准确更新 version=5 的信息：

UPDATE my_table SET price = price+50 ,version = version + 1 WHERE id = 1 AND version = 5

上面 WHERE 后面跟着条件 id=1 AND version=5 被执行后，id=1 的 version 被更新为 6，所以如果重复执行该条 SQL 语句将不生效，因为 id=1 AND version=5 的数据已经不存在，这样就能保住更新的幂等，多次更新对结果不会产生影响。

方案三：防重 Token 令牌

简单的说就是调用方在调用接口的时候先向后端请求一个全局 ID（Token），请求Token的时候后端会同步把这个Token存入redis，前端请求的时候携带这个全局 ID（Token） 一起请求（Token 最好将其放到 Headers 中），后端需要对这个 Token 作为 Key，用户信息作为 Value 到 Redis 中进行键值内容校验。情况1：如果 Key 存在且 Value 匹配就说明是第一次请求，然后正常执行后面的业务逻辑，业务执行完毕后，删除redis中的token。情况2：如果不存在对应的 Key 或 Value 不匹配就返回重复执行的错误信息，这样来保证幂等操作。

• ① 服务端提供获取 Token 的接口，该 Token 可以是一个序列号，也可以是一个分布式 ID 或者 UUID 串。

• ② 客户端调用接口获取 Token，这时候服务端会生成一个 Token 串。

• ③ 然后将该串存入 Redis 数据库中，以该 Token 作为 Redis 的键（注意设置过期时间）。

• ④ 将 Token 返回到客户端，客户端拿到后应存到表单隐藏域中。

• ⑤ 客户端在执行提交表单时，把 Token 存入到 Headers 中，执行业务请求带上该 Headers。

• ⑥ 服务端接收到请求后从 Headers 中拿到 Token，然后根据 Token 到 Redis 中查找该 key 是否存在。

• ⑦ 服务端根据 Redis 中是否存该 key 进行判断，如果存在就正常执行业务逻辑，将该 key 删除。如果不存在就抛异常，返回重复提交的错误信息。

   注意，在并发情况下，执行 Redis 查找数据与删除需要保证原子性，否则很可能在并发下无法保证幂等性。其实现方法可以使用分布式锁或者使用 Lua 表达式来注销查询与删除操作。

方案四、下游传递唯一序列号

每次向服务端请求时候附带一个短时间内唯一不重复的序列号，该序列号可以是一个有序 ID，也可以是一个订单号，一般由下游的请求发起端生成，在调用上游服务端接口时附加该序列号和用于认证的 ID（标识会话/机器/或用户之类的ID）。

当上游服务器收到请求信息后拿取该 序列号 和下游 认证ID 进行组合，形成用于操作 Redis 的 Key，然后到 Redis 中查询是否存在对应的 Key 的键值对，根据其结果

• 如果存在，就说明已经对该下游的该序列号的请求进行了业务处理，这时可以直接响应重复请求的错误信息。

• 如果不存在，就以该 Key 作为 Redis 的键，以下游关键信息作为存储的值（例如下游商传递的一些业务逻辑信息），将该键值对存储到 Redis 中 ，然后再正常执行对应的业务逻辑即可。

• ① 下游服务生成分布式 ID 作为序列号，然后执行请求调用上游接口，并附带“唯一序列号”与请求的“认证凭据ID”。

• ② 上游服务进行安全效验，检测下游传递的参数中是否存在“序列号”和“凭据ID”。

• ③ 上游服务到 Redis 中检测是否存在对应的“序列号”与“认证ID”组成的 Key，如果存在就抛出重复执行的异常信息，然后响应下游对应的错误信息。如果不存在就以该“序列号”和“认证ID”组合作为 Key，以下游关键信息作为 Value，进而存储到 Redis 中，然后正常执行接来来的业务逻辑。