接口幂等性的几种解决方案

2020/05/04 Distributed

幂等就是一个操作,不论执行多少次,产生的效果和返回的结果都是一样的

接口幂等性的几种解决方案

幂等就是一个操作,不论执行多少次,产生的效果和返回的结果都是一样的

很多重要的情况都需要幂等的特性来支持。比如如下的几种业务场景:

  • 前端重复提交数据,应该后台只产生对应这个数据的一个响应;
  • 我们发起一笔付款请求,应该只扣用户账户一次钱;
  • 发送短信给用户,也应该也只能只发一次;
  • 创建业务订单,一次业务请求只能创建一个,创建多个就会出大问题等等。

幂等性方案

在设计幂等接口时,重点关注新增接口和更新接口。因为查询和删除操作,天生是幂等的(有些删除比较特殊,也不满足幂等性,关于这一点该文章不展开说明),不需要我们提供额外的技术手段来保证幂等性。

对于新增和更新接口,大致有以下几种方案可以保证接口幂等性。

1、唯一索引:防止新增脏数据。

比如:每个用户只能有一个资金账户,怎么防止给用户创建了多个账户呢?给资金账户表中的用户 ID 加唯一索引。

方案要点:唯一索引或唯一组合索引,用来防止新增数据的时候存在脏数据(当表存在唯一索引,并发时新增报错时,再查询一次就可以了,数据应该已经存在,直接返回查询结果);

2、token机制:防止页面重复提交。

原理上一般通过 redis 来实现。当客户端请求页面时,服务器会生成一个随机数 Token,将该 Token 放置到 redis 缓存中,然后将Token发给客户端(一般通过构造hidden表单)。 下次客户端提交请求时,Token会随着表单一起提交到服务器端。

服务器端第一次验证相同之后,会将 redis 中的 Token 值删除,若用户重复提交,第二次验证会失败,因为用户提交的表单中的 Token redis 中 Token 已经删除了。

3、悲观锁

获取数据的时候加锁获取。

select * from table_xxx where id='xxx' for update; 

注意:id 字段一定是主键或者唯一索引。悲观锁使用时一般伴随事务一起使用,数据锁定时间可能会比较长,影响服务器的性能;

4、乐观锁

乐观锁只是在更新数据那一刻锁表,其他时间不锁表,所以相对于悲观锁,效率更高。

乐观锁可以通过添加 version 来实现。

update table_xxx set name=#name#,version=version+1 where version=#version#;

5、分布式锁

如果是分布式系统,无法构建全局唯一索引,这时候可以引入分布式锁,通过中间件(redis或zookeeper)构建分布式锁。

一般的操作都是,先去获取锁,做操作,之后释放锁,这其实是把多线程并发的思路,引入多个系统。

方案要点:锁的标示怎么区分业务场景;一般是通过(用户ID+业务场景等)获取分布式锁

6、select + insert

并发不高的后台系统,或者一些任务JOB,为了支持幂等,支持重复执行,简单的处理方法是,先查询下一些关键数据,判断是否已经执行过,在进行业务处理,就可以了。

注意:核心高并发流程不要用这种方法;

7、状态机幂等

比如在设计订单状态的时候,肯定会涉及到状态机(订单状态变更),状态在不同的情况下可能需要的处理是不一样的。 如果状态机已经处于下一个状态,这时候来了一个上一个状态的变更,理论上是不能够变更的,这样的话,保证了有限状态机的幂等。

总结

幂等与是不是分布式高并发还有JavaEE都没有关系。关键是你的业务场景是不是幂等的。

在设计系统时,我们始终要考虑的问题是怎么高效的实现系统功能,并且数据也要准确,比如不能出现多扣款,多打款等等的问题。这时候就需要仔细考虑如何实现幂等性操作了。

文档信息

Search

    Table of Contents