怎么样设计一个高质量的 API 接口？

刺骨的言语ヽ痛彻心扉 2024-04-07 13:38 7阅读 0赞

一、什么是幂等性？

对于同一笔业务交易，不管调用多少次，只会成功处理一次。

二、幂等性设计

我们转账业务为例，来说明一下这个问题，转账接口一定要做到幂等性，否则会出现重复转账的问题。

调用转账接口从A中转100元资金给B，参数中会携带业务流水号biz\_no和源账户A，目的账户B，和转账金额100，业务流水号biz\_no是唯一的。转账接口实现有以下实现方式。

1 方式1（普通方式）

过程如下：

1.接收到转账请求

2.根据biz\_no查询当前订单是否处理过

3.如果订单已处理直接返回，若未处理，插入一条流水，继续向下执行

4.开启本地事务

5.本地系统给A扣减100，B账户加100

6.插入记账流水表

7.将订单状态置为成功

8.提交本地事务

上面的过程，对于同一笔订单，如果上游重复调用了两次次，会出现什么问题？当两次次请求同时到达第2步时候，查询订单都是未处理的，会继续向下执行，最终本A会转两次钱给B，总共转了200。

此方式适用于单机模式，按顺序串行执行的情况。

分析：这次出现出现重复转账的原因是，两次请求同时进来，在第一次请求插入流水提交事务之前，第二次又进来了，有人会说：如果第一次请求进来的时候，我加锁，等我处理完了，才释放锁，第二次请求就得等待，直到第一次请求释放锁，再进来，那就没问题了。

2 方式2（jvm加锁方式）

方式1中由于并发出现了问题，此时我们使用java中的Lock加锁，来防止并发操作，过程如下：

1.转账接口接收到上游的转账申请请求；

2.调用java中的Lock加锁

3.根据biz\_no查询当前订单是否处理过

4.如果订单已处理直接返回，若未处理，插入一条流水，继续向下执行

5.如果订单已处理直接返回，若未处理，继续向下执行

6 开启本地事务

7.本地系统给A扣减100，B账户加100

8.插入记账流水表

9.将订单状态置为成功

10.提交本地事务

11.释放Lock锁

分析问题：

Lock只能在一个jvm中起效，如果多个请求都被同一套系统处理，上面这种使用Lock的方式是没有问题的，不过互联网系统中，多数是采用集群方式部署，同一套代码后面会部署多套，如果上游同时发来多个请求经过负载均衡转发到不同的机器，上面的锁就不起效了。此时对于多个请求相当于无锁处理了，又会出现方式1中的结果。此时我们需要分布式锁来做处理。

3 方式3（悲观锁方式）

使用数据库中悲观锁实现。悲观锁类似于方式二中的Lock，只不过是依靠数据库来实现的。数据中悲观锁使用for update来实现，过程如下：

1.接收到转账申请请求

2.打开本地事物

3.查询订单信息并加悲观锁

select \* from t\_order where biz\_no = \#\{bizNo\} for update;

4.判断订单是已处理

5.如果订单已处理直接返回，若未处理，插入一条流水，继续向下执行

6.本地系统给A扣减100，B账户加100

7.插入记账流水表

8.将订单状态置为成功

8.提交本地事物

分析：重点在于for update，对for update，做一下说明：

1.当线程A执行for update，数据会对当前记录加锁进行行锁，其他线程执行到此行代码的时候，会等待线程A释放锁之后，才可以获取锁，继续后续操作。

2.事物提交时，for update获取的锁会自动释放。

方式3可以正常实现我们需要的效果，能保证接口的幂等性，不过存在一些缺点：

1.这种方式性能比较差，并发情况下，后面线程会长期处于等待状态，占用了很多线程，让这些线程处于无效等待状态，我们的web服务中的线程数量一般都是有限的，如果大量线程由于获取for update锁处于等待状态，不利于系统并发操作。

4 方式4（乐观锁方式）

依靠数据库中的乐观锁来实现。

1.接收到转账申请请求

2.查询订单信息

select \* from t\_order where biz\_no = \#\{bizNo\};

3.判断订单是已处理

4.如果订单已处理直接返回，若未处理，插入一条流水，继续向下执行

5.打开本地事物

6.本地系统给A扣减100，B账户加100

7.插入记账流水表

8.将订单状态置为成功，注意这块是重点，伪代码：

update t\_order set status = 1 where biz\_no = \#\{bizNo\} where status = 0;

//上面的update操作会返回影响的行数num

if(num==1)\{

//表示更新成功

提交事务;

\}else\{

//表示更新失败

回滚事务;

注意：

update t\_order set status = 1 where biz\_no = \#\{bizNo\} where status = 0; 是依靠乐观锁来实现的，status=0作为条件去更新.

执行这条sql的时候，如果有多个线程同时到达这条代码，数据内部会保证update同一条记录会排队执行，最终最有一条update会执行成功，其他未成功的，他们的num为0，然后根据num来进行提交或者回滚操作。

5 方式5（唯一约束方式）

依赖数据库中唯一约束来实现。

我们可以创建一个表：

CREATE TABLE \`t\_unique\_controler\` (

\`id\` bigint(20) NOT NULL AUTO\_INCREMENT,

\`unique\_biz\_no\` varchar(64) NOT NULL DEFAULT '' COMMENT '流水号',

PRIMARY KEY (\`id\`),

UNIQUE KEY \`unique\_biz\_no\` (\`unique\_biz\_no\`) COMMENT '保证业务唯一性'

) ENGINE=InnoDB;

对于任何一笔转账请求，有一个唯一全局的业务流水号，请求进来来的时候，先查询t\_unique\_controler表中是否存在相关记录，若不存在，继续放行。

过程如下：

1.接收到转账申请请求

2.查询t\_unique\_controler(条件unique\_biz\_no)，可以判断订单是否已处理

select \* from t\_unique\_controler where unique\_biz\_no = \#\{unique\_biz\_no\};

3.判断订单是已处理

4.如果订单已处理直接返回，若未处理，插入一条流水，继续向下执行

5.打开本地事物

6.本地系统给A扣减100，B账户加100

7.插入记账流水表

7.将订单状态置为成功

8.向t\_uq\_dipose插入数据，插入成功，提交本地事务，插入失败，回滚本地事务，伪代码：

try\{

insert into t\_unique\_controler (unique\_biz\_no) values (\#\{unique\_biz\_no\});

提交本地事务：

\}catch(Exception e)\{

回滚本地事务;

说明：

对于同一笔转账请求，业务流水号unique\_biz\_no是一样的，当并发时，插入数据只会有一条成功，其他的会违法唯一约束，进入catch逻辑，当前事务会被回滚，最终最有一个操作会成功，从而保证了幂等性操作。

关于这种方式可以写成通用的方式，不过业务量大的情况下，t\_unique\_controler插入数据会成为系统的瓶颈，需要考虑分表操作，解决性能问题。

上面的过程中向t\_unique\_controler插入记录，最好放在最后执行，原因：插入操作会锁表，放在最后能让锁表的时间降到最低，提升系统的并发性。

关于消息服务中，消费者如何保证消息处理的幂等性？

每条消息都有一个唯一的消息id，类似于上面业务中的unique\_biz\_no，使用上面的方式即可实现消息消费的幂等性。

三、总结

1.实现幂等性常见的方式有：悲观锁（for update）、乐观锁、唯一约束

2.几种方式，按照最优排序：乐观锁 > 唯一约束 > 悲观锁

怎么样设计一个高质量的 API 接口？

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关怎么样设计一个高质量的 API 接口？

相关如何设计一个安全逼格高的接口？

相关接口（API）设计规范

相关如何编写高质量前端设计文档？

相关一个API设计网站

相关 API接口安全性设计

相关 API接口安全性设计

相关如何设计一个牛逼的API接口

相关如何设计一个牛逼的 API 接口

相关 restful api接口设计