java开发的时候,我们经常会遇到接口幂等性的要求。相信大家都能耳熟能详介绍几种接口幂等性的方案。但是很多同学在介绍这些方案的时候确不是能完全的介绍清楚,导致一些错漏百出。这篇文章我们就来详细的介绍下java中实现接口幂等性的主要的4种方案。
第一种方案:数据库唯一主键
方案描述
数据库唯一主键的实现主要是利用数据库中主键唯一约束的特性,一般来说唯一主键比较适用于“插入”时的幂等性,其能保证一张表中只能存在一条带该唯一主键的记录。
使用数据库唯一主键完成幂等性时需要注意的是,该主键一般来说并不是使用数据库中自增主键,而是使用分布式 ID 充当主键,这样才能能保证在分布式环境下 ID 的全局唯一性。
适合操作
1、插入操作 2、删除操作
使用限制
需要生成全局唯一主键 ID
主要流程
主要流程
1、客户端执行创建请求,调用服务端接口。
2、服务端执行业务逻辑,生成一个分布式 ID,将该 ID 充当待插入数据的主键,然后执数据插入操作,运行对应的 SQL 语句。
3、服务端将该条数据插入数据库中,如果插入成功则表示没有重复调用接口。如果抛出主键重复异常,则表示数据库中已经存在该条记录,返回错误信息到客户端。
第二种方案:数据库乐观锁
方案描述
数据库乐观锁方案一般只能适用于执行“更新操作”的过程,我们可以提前在对应的数据表中多添加一个字段,充当当前数据的版本标识。这样每次对该数据库该表的这条数据执行更新时,都会将该版本标识作为一个条件,值为上次待更新数据中的版本标识的值。
适合操作
更新操作
使用限制
需要数据库对应业务表中添加额外字段
描述示例
例如存储在表的中的数据如下:
id | name | price |
---|---|---|
1 | 小米手机 | 1000 |
2 | 苹果手机 | 2500 |
3 | 华为手机 | 1600 |
为了每次执行更新时防止重复更新,确定更新的一定是要更新的内容,我们通常都会添加一个 version 字段记录当前的记录版本,这样在更新时候将该值带上,那么只要执行更新操作就能确定一定更新的是某个对应版本下的信息。
id | name | price | version |
---|---|---|---|
1 | 小米手机 | 1000 | 10 |
2 | 苹果手机 | 2500 | 21 |
3 | 华为手机 | 1600 | 5 |
这样每次执行更新时候,都要指定要更新的版本号,如下操作就能准确更新 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),请求的时候携带这个全局 ID 一起请求(Token 最好将其放到 Headers 中),后端需要对这个 Token 作为 Key,用户信息作为 Value 到 Redis 中进行键值内容校验,如果 Key 存在且 Value 匹配就执行删除命令,然后正常执行后面的业务逻辑。如果不存在对应的 Key 或 Value 不匹配就返回重复执行的错误信息,这样来保证幂等操作。
适合操作
1、插入操作 2、更新操作 3、删除操作
使用限制
1、需要生成全局唯一 Token 串 2、需要使用第三方组件 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、在并发情况下,执行 Redis 查找数据与删除需要保证原子性,否则很可能在并发下无法保证幂等性。其实现方法可以使用分布式锁或者使用 Lua 表达式来注销查询与删除操作。
第四种方案:下游传递唯一序列号
方案描述
所谓请求序列号,其实就是每次向服务端请求时候附带一个短时间内唯一不重复的序列号,该序列号可以是一个有序 ID,也可以是一个订单号,一般由下游生成,在调用上游服务端接口时附加该序列号和用于认证的 ID。
当上游服务器收到请求信息后拿取该 序列号 和下游 认证ID 进行组合,形成用于操作 Redis 的 Key,然后到 Redis 中查询是否存在对应的 Key 的键值对,根据其结果:
如果存在,就说明已经对该下游的该序列号的请求进行了业务处理,这时可以直接响应重复请求的错误信息。
如果不存在,就以该 Key 作为 Redis 的键,以下游关键信息作为存储的值(例如下游商传递的一些业务逻辑信息),将该键值对存储到 Redis 中 ,然后再正常执行对应的业务逻辑即可。
适用操作
1、插入操作 2、更新操作 3、删除操作
使用限制
1、要求第三方传递唯一序列号 2、需要使用第三方组件 Redis 进行数据效验;
主要流程
主要流程
1、下游服务生成分布式 ID 作为序列号,然后执行请求调用上游接口,并附带“唯一序列号”与请求的“认证凭据ID”。
2、上游服务进行安全效验,检测下游传递的参数中是否存在“序列号”和“凭据ID”。
3、上游服务到 Redis 中检测是否存在对应的“序列号”与“认证ID”组成的 Key,如果存在就抛出重复执行的异常信息,然后响应下游对应的错误信息。如果不存在就以该“序列号”和“认证ID”组合作为 Key,以下游关键信息作为 Value,进而存储到 Redis 中,然后正常执行接来来的业务逻辑。
备注:
1、上面步骤中插入数据到 Redis 一定要设置过期时间。这样能保证在这个时间范围内,如果重复调用接口,则能够进行判断识别。如果不设置过期时间,很可能导致数据无限量的存入 Redis,致使 Redis 不能正常工作。
还没有评论,来说两句吧...