幂等性介绍

接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的,不会因为多次点击而产生了副作用;比如说支付场景,用户购买了商品支付扣款成功,但是返回结果的时候网络异常,此时钱已经扣了,用户再次点击按钮,此时会进行第二次扣款,返回结果成功,用户查询余额返发现多扣钱了,流水记录也变成了两条,这就没有保证接口的幂等性。

再比如在金融业务中,如果两个机构发出交易动作,这个时候会向数据库中插入一条成交记录,如果此时因为网络问题或者用户多次点击操作,会向数据库中插入两条成交记录,因此不符合幂等性设计。

为什么需要幂等性设计

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

• 前端重复提交表单: 在填写一些表格时候,用户填写完成提交,很多时候会因网络波动没有及时对用户做出提交成功响应,致使用户认为没有成功提交,然后一直点提交按钮,这时就会发生重复提交表单请求。
• 用户恶意进行刷单: 例如在实现用户投票这种功能时,如果用户针对一个用户进行重复提交投票,这样会导致接口接收到用户重复提交的投票信息,这样会使投票结果与事实严重不符。
• 接口超时重复提交: 很多时候 HTTP 客户端工具都默认开启超时重试的机制,尤其是第三方调用接口时候,为了防止网络波动超时等造成的请求失败,都会添加重试机制,导致一个请求提交多次。
• 消息进行重复消费: 当使用 MQ 消息中间件时候,如果发生消息中间件出现错误未及时提交消费信息,导致发生重复消费。

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

哪些情况需要做幂等性设计

• 用户多次点击按钮
• 用户页面回退再次提交
• 微服务互相调用,由于网络问题,导致请求失败。feign 触发重试机制
• 其他业务情况
• 网络波动, 可能会引起重复请求
• 用户重复操作,用户在操作时候可能会无意触发多次下单交易,甚至没有响应而有意触发多次交易应用
• 使用了失效或超时重试机制(Nginx重试、RPC重试或业务层重试等)
• 页面重复刷新
• 使用浏览器后退按钮重复之前的操作,导致重复提交表单
• 使用浏览器历史记录重复提交表单
• 浏览器重复的HTTP请求
• 定时任务重复执行
• 用户双击提交按钮

现在流行的 Restful 推荐的几种 HTTP 接口方法中,分别存在幂等行与不能保证幂等的方法,如下:

方法类型	是否幂等	描述
Get	是	Get 方法用于获取资源。其一般不会也不应当对系统资源进行改变,所以是幂等的。
Post	否	Post 方法一般用于创建新的资源。其每次执行都会新增数据,所以不是幂等的。
Put	分情况	Put 方法一般用于修改资源。该操作则分情况来判断是不是满足幂等,更新操作中直接根据某个值进行更新,也能保持幂等。不过执行累加操作的更新是非幂等。
Delete	分情况	Delete 方法一般用于删除资源。该操作则分情况来判断是不是满足幂等,当根据唯一值进行删除时,删除同一个数据多次执行效果一样。不过需要注意,带查询条件的删除则就不一定满足幂等了。例如在根据条件删除一批数据后,这时候新增加了一条数据也满足条件,然后又执行了一次删除,那么将会导致新增加的这条满足条件数据也被删除。

以 SQL 为例,有些操作天然是幂等的:

• SELECT * FROM table WHER id=?,无论执行多少次都不会改变状态,是天然的幂等。
• UPDATE tab1 SET col1=1 WHERE col2=2,无论执行成功多少次状态都是一致的,也是幂等操作。
• delete from user where userid=1,多次操作,结果一样,具备幂等性
• insert into user(userid,name) values(1,'a') 如 userid 为唯一主键,即重复操作上面的业务,只 会插入一条用户数据,具备幂等性。

下面这条sql语句不是符合幂等性:

• UPDATE tab1 SET col1=col1+1 WHERE col2=2,每次执行的结果都会发生变化,不是幂等的。
• insert into user(userid,name) values(1,'a') 如 userid 不是主键,可以重复,那上面业务多次操作,数据都会新增多条,不具备幂等性

引入幂等性设计对系统的影响

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

• 把并行执行的功能改为串行执行,降低了执行效率。
• 增加了额外控制幂等的业务逻辑,复杂化了业务功能;

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

幂等性解决方案

数据库唯一主键

方案

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

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

适用操作

• 插入操作
• 删除操作

需要全局唯一生成id

主要流程

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

如果是分库分表场景下,路由规则要保证相同请求下,落地在同一个数据库和同一表中,要不然数据库主键约束就不起效果了,因为是不同的数据库和表主键不相关。

数据库乐观锁

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

通常对数据库增加一个version字段,每次做更新的时候适用version字段和上一次做比较,如果相等在更新,缺点是需要添加额外的字段,并且只适用于更新操作。

业务层分布式锁

如果多个机器可能在同一时间同时处理相同的数据,比如多台机器定时任务都拿到了相同数据处理,我们就可以加分布式锁,锁定此数据,处理完成后释放锁。获取到锁的必须先判断这个数据是否被处理过。

各种唯一约束

1、数据库唯一约束

插入数据,应该按照唯一索引进行插入,比如订单号,相同的订单就不可能有两条记录插入。我们在数据库层面防止重复。 这个机制是利用了数据库的主键唯一约束的特性,解决了在 insert 场景时幂等问题。但主键的要求不是自增的主键,这样就需要业务生成全局唯一的主键。

如果是分库分表场景下,路由规则要保证相同请求下,落地在同一个数据库和同一表中,要不然数据库主键约束就不起效果了,因为是不同的数据库和表主键不相关。

2、redis set 防重

很多数据需要处理,只能被处理一次,比如我们可以计算数据的 MD5 将其放入 redis 的 set,每次处理数据,先看这个 MD5 是否已经存在,存在就不处理。

4、防重表

使用订单号 orderNo 做为去重表的唯一索引,把唯一索引插入去重表,再进行业务操作,且他们在同一个事务中。这个保证了重复请求时,因为去重表有唯一约束,导致请求失败,避免了幂等问题。这里要注意的是,去重表和业务表应该在同一库中,这样就保证了在同一个事务,即使业务操作失败了,也会把去重表的数据回滚。这个很好的保证了数据一致性。之前说的 redis 防重也算。

5、全局请求唯一 id

调用接口时,生成一个唯一 id,redis 将数据保存到集合中（去重）,存在即处理过。可以使用 nginx 设置每一个请求的唯一 id; proxy_set_header X-Request-Id $request_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 删除,然后正常执行业务逻辑。如果不存在就抛异常,返回重复提交的错误信息。

危险操作

1、先删除 token 还是后删除 token; a.、先删除可能导致,业务确实没有执行,重试还带上之前 token,由于防重设计导致,请求还是不能执行。

​ b、后删除可能导致,业务处理成功,但是服务闪断,出现超时,没有删除 token,别人继续重试,导致业务被执行两边

​ c、我们最好设计为先删除 token,如果业务调用失败,就重新获取 token 再次请求。 2、Token 获取、比较和删除必须是原子性 ​ a、redis.get(token) 、token.equals、redis.del(token)如果这两个操作不是原子,可能导致,高并发下,都 get 到同样的数据,判断都成功,继续业务并发执行 ​ b、可以在 redis 使用 lua 脚本完成这个操作

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

执行成功:执行成功说明存在该Token,是第一次调用该接口,允许执行后续的业务过程

执行失败:说明Redis中不存在该Token,不是第一次调用该接口,不允许执行后面的业务调用过程

下游传递唯一序列号

方案描述:

所谓请求序列号,其实就是每次向服务端请求时候附带一个短时间内唯一不重复的序列号,该序列号可以是一个有序 ID,也可以是一个订单号,一般由下游生成,在调用上游服务端接口时附加该序列号和用于认证的 ID。

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

• 如果存在,就说明已经对该下游的该序列号的请求进行了业务处理,这时可以直接响应重复请求的错误信息。
• 如果不存在,就以该 Key 作为 Redis 的键,以下游关键信息作为存储的值（例如下游商传递的一些业务逻辑信息）,将该键值对存储到 Redis 中 ,然后再正常执行对应的业务逻辑即可。

适用操作:

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

使用限制:

• 要求第三方传递唯一序列号;
• 需要使用第三方组件 Redis 进行数据效验;

主要步骤:

1. 下游服务生成分布式 ID 作为序列号,然后执行请求调用上游接口,并附带“唯一序列号”与请求的“认证凭据ID”。
2. 上游服务进行安全效验,检测下游传递的参数中是否存在“序列号”和“凭据ID”。
3. 上游服务到 Redis 中检测是否存在对应的“序列号”与“认证ID”组成的 Key,如果存在就抛出重复执行的异常信息,然后响应下游对应的错误信息。如果不存在就以该“序列号”和“认证ID”组合作为 Key,以下游关键信息作为 Value,进而存储到 Redis 中,然后正常执行接来来的业务逻辑。

上面步骤中插入数据到 Redis 一定要设置过期时间。这样能保证在这个时间范围内,如果重复调用接口,则能够进行判断识别。如果不设置过期时间,很可能导致数据无限量的存入 Redis,致使 Redis 不能正常工作。

项目经验

在交易系统中,对订单编号进行了设计,根据当天时间戳生成唯一的订单成交编号,订单编号作为主键,保证对订单的插入,删除等操作的幂等性。

贡献者

codingLab

版权所有

版权归属：codingLab

许可证：bugcode