接口幂等性

什么是幂等性？

幂等是一个数学与计算机学概念，在数学中某一元运算为幂等时，其作用在任一元素两次后会和其作用一次的结果相同。

“ 在计算机中编程中，一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。

幂等函数或幂等方法是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。

什么是接口幂等性？

对幂等性进行了定义。它描述了一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外），即第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。

这里的副作用是不会对结果产生破坏或者产生不可预料的结果。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。

其实在我们编程中主要操作就是CURD，其中读取（Retrieve）操作是天然幂等的，受影响的就是创建（Create）、更新（Update）、删除（Delete）操作。

为什么需要实现幂等性？

在接口调用时一般情况下都能正常返回信息不会重复提交，不过在遇见以下情况时可以就会出现问题，如：

1. 前端重复提交表单： 在填写一些表格时候，用户填写完成提交，很多时候会因网络波动没有及时对用户做出提交成功响应，致使用户认为没有成功提交，然后一直点提交按钮，这时就会发生重复提交表单请求。
2. 接口超时重试：对于给第三方调用的接口，为了防止网络抖动或其他原因造成请求丢失，这样的接口一般都会设计成超时重试多次。
3. 消息进行重复消费： 当使用 MQ 消息中间件时候，如果发生消息中间件出现错误未及时提交消费信息，导致发生重复消费。

“ 使用幂等性最大的优势在于使接口保证任何幂等性操作，免去因重试等造成系统产生的未知的问题。

引入幂等性后对系统有什么影响？

幂等性是为了简化客户端逻辑处理，能放置重复提交等操作，但却增加了服务端的逻辑复杂性和成本，其主要是：

1. 把并行执行的功能改为串行执行，降低了执行效率。
2. 增加了额外控制幂等的业务逻辑，复杂化了业务功能；

所以在使用时候需要考虑是否引入幂等性的必要性，根据实际业务场景具体分析，除了业务上的特殊要求外，一般情况下不需要引入的接口幂等性。

接口幂等性技术方案

方案一：数据库唯一主键

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

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

适用操作

• 插入操作
• 删除操作

使用限制

• 需要生成全局唯一主键 ID；

主要流程

主要流程如下：

1. 客户端执行创建请求，调用服务端接口。
2. 服务端执行业务逻辑，生成一个分布式 ID，将该 ID 充当待插入数据的主键，然 后执数据插入操作，运行对应的 SQL 语句。
3. 服务端将该条数据插入数据库中，如果插入成功则表示没有重复调用接口。如果抛出主键重复异常，则表示数据库中已经存在该条记录，返回错误信息到客户端。

方案二：数据库乐观锁

数据库乐观锁方案一般只能适用于执行更新操作的过程，我们可以提前在对应的数据表中多添加一个字段，充当当前数据的版本标识。

这样每次对该数据库该表的这条数据执行更新时，都会将该版本标识作为一个条件，值为上次待更新数据中的版本标识的值。

适用操作

• 更新操作

使用限制

• 需要数据库对应业务表中添加额外字段

描述示例

方案三：数据库悲观锁（不建议使用）

获取数据的时候加锁获取。select * from table where id=xxx for update，id字段尽量是主键或者唯一索引，如果使用不当，会存在严重的性能问题，不建议使用

适用操作

• 更新操作
• 删除操作

描述示例

方案四：防重 Token 令牌

针对客户端连续点击或者调用方的超时重试等情况，例如提交订单，此种操作就可以用 Token 的机制实现防止重复提交。

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

适用操作

• 插入操作
• 更新操作
• 删除操作

使用限制

• 需要生成全局唯一 Token 串
• 需要使用第三方组件 Redis 进行数据效验

主要流程：

1. 服务端提供获取 Token 的接口，该 Token 可以是一个序列号，也可以是一个分布式 ID 或者 UUID 串。
2. 客户端调用接口获取 Token，这时候服务端会生成一个 Token 串。
3. 然后将该串存入 Redis 数据库中，以该 Token 作为 Redis 的键（注意设置过期时间）。
4. 将 Token 返回到客户端，客户端拿到后应存到表单隐藏域中。
5. 客户端在执行提交表单时，把 Token 存入到 Headers 中，执行业务请求带上该 Headers。
6. 服务端接收到请求后从 Headers 中拿到 Token，然后根据 Token 到 Redis 中查找该 key 是否存在。
7. 服务端根据 Redis 中是否存该 key 进行判断，如果存在就将该 key 删除，然后正常执行业务逻辑。如果不存在就抛异常，返回重复提交的错误信息。

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

方案五: 状态机

对于很多业务是有一个业务流转状态的，每个状态都有前置状态和后置状态，以及最后的结束状态。例如流程的待审批，审批中，驳回，重新发起，审批通过，审批拒绝。订单的待提交，待支付，已支付，取消。

以订单为例，已支付的状态的前置状态只能是待支付，而取消状态的前置状态只能是待支付，通过这种状态机的流转我们就可以控制请求的幂等

适用操作

• 更新操作

使用限制

• 需维护各个状态的前置及后置状态

主要流程

方案六:分布式锁

通过redis的set或setnx分布式锁命令来实现幂等性。

适用操作

• 插入操作
• 更新操作
• 删除操作

使用限制

• 需构建全局唯一key
• 需使用第三方组件 Redis 进行数据效验

主要流程

方案七: redis模式

同分布式锁主要区别：缓存value中需要记录业务逻辑的结果信息

适用操作

• 插入操作
• 更新操作
• 删除操作

使用限制

• 需构建全局唯一key
• 需使用第三方组件 Redis 进行数据效验

主要流程

最后总结

幂等性是开发当中很常见也很重要的一个需求，尤其是支付、订单等与金钱挂钩的服务，保证接口幂等性尤其重要。在实际开发中，我们需要针对不同的业务场景我们需要灵活的选择幂等性的实现方式：

1. 对于下单等存在唯一主键的，可以使用“唯一主键方案”的方式实现。
2. 对于更新订单状态等相关的更新场景操作，使用“乐观锁方案”实现更为简单。
3. 对于那些‘重复消费‘’和‘接口重试‘的场景则使用“唯一主键方案"或"分布式锁"的方式实现更合理。
4. 类似于前端重复提交、重复下单、没有唯一ID号的场景，可以通过 Token 与 Redis 配合的“防重 Token 方案”实现更为快捷。
5. 对于那些有状态前置和后置转换的场景，则可以通过“状态机“的方式实现幂等性
6. 对于对外api接口的场景，使用“reids模式“方式更合理。

上面只是给与一些建议，再次强调一下，实现幂等性需要先理解自身业务需求，根据业务逻辑来实现这样才合理，处理好其中的每一个结点细节，完善整体的业务流程设计，才能更好的保证系统的正常运行。

 

 

美团通过自研的GTIS来实现的接口幂等性

参考链接：https://tech.meituan.com/2016/09/29/distributed-system-mutually-exclusive-idempotence-cerberus-gtis.html

GTIS

GTIS：它是一个轻量的重复操作关卡系统，它能够确保在分布式环境中操作的唯一性。我们可以用它来间接保证每个操作的幂等性。

它具有如下特点：

*高效：低延时，单个方法平均响应时间在2ms内，几乎不会对业务造成影响；

* 可靠：提供降级策略，以应对外部存储引擎故障所造成的影响；提供应用鉴权，提供集群配置自定义，降低不同业务之间的干扰；

* 简单：接入简捷方便，学习成本低。只需简单的配置，在代码中进行两个方法的调用即可完成所有的接入工作；

* 灵活：提供多种接口参数、使用策略，以满足不同的业务需求。

实现原理

基本原理

GTIS的实现思路是将每一个不同的业务操作赋予其唯一性。这个唯一性是通过对不同操作所对应的唯一的内容特性生成一个唯一的全局ID来实现的。基本原则为：相同的操作生成相同的全局ID；不同的操作生成不同的全局ID。

生成的全局ID需要存储在外部存储引擎中，数据库、Redis亦或是Tair等等均可实现。考虑到Tair天生分布式和持久化的优势，目前的GTIS存储在Tair中。其相应的key和value如下：

• key：将对于不同的业务，采用APP_KEY+业务操作内容特性生成一个唯一标识trans_contents。然后对唯一标识进行加密生成全局ID作为Key。
• value：current_timestamp + trans_contents，current_timestamp用于标识当前的操作线程。

判断是否重复，主要利用Tair的SETNX方法，如果原来没有值则set且返回成功，如果已经有值则返回失败。

内部流程

GTIS的内部实现流程为：

1. 业务方在业务操作之前，生成一个能够唯一标识该操作的transContents，传入GTIS；
2. GTIS根据传入的transContents，用MD5生成全局ID；
3. GTIS将全局ID作为key，current_timestamp+transContents作为value放入Tair进行setNx，将结果返回给业务方；
4. 业务方根据返回结果确定能否开始进行业务操作；
5. 若能，开始进行操作；若不能，则结束当前操作；
6. 业务方将操作结果和请求结果传入GTIS，系统进行一次请求结果的检验；
7. 若该次操作成功，GTIS根据key取出value值，跟传入的返回结果进行比对，如果两者相等，则将该全局ID的过期时间改为较长时间；
8. GTIS返回最终结果。

实现难点

GTIS的实现难点在于如何保证其判断重复的可靠性。由于分布式环境的复杂度和业务操作的不确定性，分布式锁的实现中考虑的网络断开或主机宕机等等问题，同样需要在GTIS中设法解决。这里列出几个典型的场景：

• 如果操作执行失败，理想的情况应该是另一个相同的操作可以立即进行。因此，需要对业务方的操作结果进行判断，如果操作失败，那么就需要立即删除该全局ID；
• 如果操作超时或主机宕机，当前的操作无法告知GTIS操作是否成功。那么我们必须引入超时机制，一旦长时间获取不到业务方的操作反馈，那么也需要该全局ID失效；
• 结合上两个场景，既然全局ID会失效并且可能会被删除，那就需要保证删除的不是另一个相同操作的全局ID。这就需要将特殊的标识记录下来，并由此来判断。这里所用的标识为当前时间戳。

使用说明

使用时，业务方只需要在操作的前后调用GTIS的前置方法和后置方法，如下图所示。如果前置方法返回可进行操作，则说明此时无重复操作，可以进行。否则则直接结束操作。

使用方需要考虑的主要是下面两个参数：

• 空间全局性：业务方输入的能够标志操作唯一性的内容特性，可以是唯一性的String类型的ID，也可以是map、POJO等形式。如订单ID等
• 时间全局性：确定在多长时间内不允许重复，1小时内还是一个月内亦或是永久。

此外，GTIS还提供了不同的故障处理策略和重试机制，以此来降低外部存储引擎异常对系统造成的影响。

目前，GTIS已经持续迭代了7个版本，距离第一个版本有近1年之久，先后在美团点评多个项目中稳定运行。