接口的幂等性的多重考虑，你会了吗？

目录

文章目录

• • 目录
  • 前言
  • 正文
  • • 1 接口幂等性
    • 1.1 案例
    • 2 解决方案
    • 2.1 token机制
    • 2.2 去重表
    • 2.3 redis 的 SETNX键值
    • 2.4 状态机幂
    • 2.5 乐观锁(更新操做)
    • 2.6 悲观锁(更新操做)
  • 结语

前言

    今天的主题：接口幂等性的解决方案。原本是想把对象的存储过程和内存布局肝出来的，可是临时产生了变化，哈哈，这部份内容咱们留在下一期吧，有句话说的好，好事多磨，对吧。

    在实际项目开发中接口是咱们在开发中常常接触到的，并且是常常常常要写，每个项目可能都会伴随着大量的接口开发，在moon来涂鸦的这几个月，基本上就是在与接口做斗争了，新需求除了业务相关就是设计表和接口编写了。

    固然，在接口设计中咱们要考虑不少问题，安全性，格式，设计等等，今天咱们先来聊聊，在高并发环境下，接口幂等性的解决方案有哪些。

正文

1 接口幂等性

     就是说在屡次相同的操做下保证最终的结果是一致的。

    其实这个概念仍是比较简单的，很容易理解，那咱们思考一个问题，若是不保证接口幂等性会有什么问题？

1.1 案例

    咱们简单的举个例子，如今有一个接口，提供了转帐的功能，a要给b转帐1000元，正常状况下咱们接口一次性就调用成功了，可是却由于网络抖动等其它缘由没有成功，因而就开始不停的重试，忽然网络好了，可是这时却连续发出去了三个请求，可是这个接口没有保证幂等性，因而从结果上来看就是a给b转了3000元，这显然是程序业务逻辑上不能接受的(其实moon能够当b的)。

2 解决方案

2.1 token机制

    token机制实际上是比较简单的，咱们先来简单的说一下流程。

• 首先客户端先请求服务端，服务端生成token，每次请求生成的都是一个新的token(这个token必定要设置超时时间)，将token存入redis当中，而后将token返回给客户端。
• 客户端携带刚刚返回的token请求服务端作业务请求。
• 服务端收到请求，作判断。
  • 若是token在redis中，则直接删除该token，而后继续作业务请求。
  • 若是token不在redis中，表明已经执行过当前业务了，则不执行业务。

    图示以下：

    token机制实现方式仍是比较简单的，可是其实对于咱们某些响应速度要求很高的业务不太友好，缺点就是须要多一次请求获取token的过程。

    正常来讲是每次请都会生成一个新的token，若是有极限状况下，有两个请求都带着相同的token进来，会存在都走入判断是否存在的过程，可能都会同时查到存在，这样也会有问题，针对这种状况，咱们能够在删除前判断下是否存在，存在就删除，为了保证原子性，这部分逻辑建议使用lua脚本完成。

2.2 去重表

    去重表的机制是根据mysql惟一索引的特性来的，咱们先来讲下它的流程：

• 首先客户端先请求服务端，服务端先将此次的请求信息存入一张mysql的去重表中，这张表要根据此次请求的其中某个特殊字段创建惟一索引，或者主键索引。
• 判断是否插入成功
  • 若是插入成功，则继续作后续业务请求。
  • 若是插入失败，则表明已经执行过当前请求。

    图示以下：

    去重表机制的问题有两点：

• 1.mysql容错性，也就是mysql自己若是不是高可用的那么业务可能会受到影响：
• 2.既然是惟一索引，天然在写表的时候就没有办法用到changbuffer，每次都要从磁盘查出来判断再写入，对于一个高并发的接口来讲，这些都是须要考虑的因素。

2.3 redis 的 SETNX键值

    过程以下：

• 首先客户端先请求服务端，服务端将能表明此次请求业务的惟一字段以 SETNX 的方式存入redis，并设置超时时间，超时时间能够根据业务权衡。
• 判断是否插入成功
  • 若是插入成功，则继续作后续业务请求。
  • 若是插入失败，则表明已经执行过当前请求。

    这里咱们是利用了redis setnx 的特性来完成的。

    setnx:只在键key不存在的状况下，将键key的值设置为value。若键key已经存在，则SETNX命令不作任何动做。命令在设置成功时返回1，设置失败时返回0。

    图示以下：

    这种方案能够说是针对上一个方案改进的，效率也会提升不少。

2.4 状态机幂

    这种机制适用于有不一样状态的业务，moon的上一家公司就是这样作的。

    咱们的订单系统，一条订单会有多个状态，如：待付款，锁定，已付款等状态，而这些状态都是有流程和逻辑的，咱们能够根据这个状态判断是否执行后续业务操做。

2.5 乐观锁(更新操做)

    就是数据库中增长版本号字段，每次更新根据版本号来判断

    过程以下：

• 首先客户端先请求服务端，先查询出当前的version版本。
  • select version from … where …
• 根据version版原本作sql操做
  • UPDATE … SET … version=(version+1) WHERE … AND version=version;

    这个图示我就再也不画了，仍是比较简单的

2.6 悲观锁(更新操做)

    假设每一次拿数据，都有认为会被修改，因此给数据库的行上锁，也是基于数据库特性来完成。

     当数据库执行select for update时会获取被select中的数据行的行锁，所以其余并发执行的select for update若是试图选中同一行则会发生排斥（须要等待行锁被释放），所以达到锁的效果。

START TRANSACTION; # 开启事务
SELETE * FROM TABLE WHERE .. FOR UPDATE;
UPDATE TABLE SET ... WHERE ..;
COMMIT; # 提交事务

结语

    关于接口幂等性这部份内容，解决方案其实大同小异，不少方式的原理都是同样的，更多的其实都是在业务链路中去过滤，也会有不少是有消息中间件去解决的，默认在中间件这一层就直接过滤掉了，固然每种方式都有各自的优势和缺点，须要结合当前的业务去选择，今天的文章内容，你get到了吗？

    我是moon，下一篇，真的要讲jvm了~ 下次见~