接口的幂等性问题

1 什么是接口幂等性

HTTP1.1中对幂等性的定义为，一次和多次请求某一个资源对于资源本身应该具有同样的结果，网络超时等问题除外，意思就是任意多次执行所产生的影响均与一次执行的影响相同。

2 幂等性的作用

前端页面重复提交相同的数据，后台服务只产生同样的反应结果。

在网上购物时，用户购买商品后，发起支付操作，支付系统处理支付成功后，由于网络问题没有及时返回支付结果，但订单已经生成并扣款，用户可能会再次点击支付，此时第二次支付是不生效的，这就是接口幂等性。如果支付接口没有做幂等处理，那么就会发生用户购买一件商品但支付两次的情况，这种问题是致命的。

3 接口的幂等性

HTTP方法的幂等性信息如下表：



方法类型	是否幂等	描述
Get	是	Get 方法用于获取资源，一般不会对系统资源进行改变，所以满足幂等
Post	否	Post 方法一般用于创建新的资源，其每次执行都会新增数据，所以不满足幂等
Put	是	Put 方法一般用于修改资源，更新操作中直接根据某个值进行更新，一次和多次操作对资源产生的影响是相同的，所以满足幂等
Delete	是	Delete 方法一般用于删除资源，调用一次和多次对资源产生的影响是相同的，所以满足幂等性

4 实现幂等性

4.1 数据库唯一主键

数据库唯一主键主要利用主键唯一约束的特性，适用于新增数据时的幂等性，能保证数据库表中只存在一条具有该主键的记录。

注：此处的主键指使用分布式ID（雪花算法等），而不是数据库中的自增主键ID。

流程：

1.客户端调用接口，执行请求。

2.服务端生成唯一ID，将此ID作为数据库主键，执行数据插入操作。

3.如果插入成功，则表示客户端没有重复调用接口。若插入失败，则表示唯一主键重复插入，数据库中已存在该条记录，客户端重复调用接口，服务端返回客户端错误信息。

4.2 数据库乐观锁

乐观锁一般适用于执行更新操作，首先在数据库表中添加数据版本标识字段，在对数据进行更新时，将该标识字段作为更新条件，该字段值为待更新数据中的版本标识的值。

乐观锁（ Optimistic Locking ） 是相对悲观锁而言的，悲观锁认为数据在被修改的时候一定会存在并发问题，因此在整个数据处理过程中将数据锁定。乐观锁假设数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。

相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本。

乐观锁主要有两个步骤：冲突检测和数据更新。具体实现主要是Compare and Swap(CAS)技术。

CAS是项乐观锁技术，当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。

4.3 防重 Token 令牌

在调用服务端接口时先请求一个全局Token，请求时携带该Token，服务端保存该Token，每次请求时对这个Token进行校验，如果校验成功，则执行请求命令，否则不执行操作。该方法需使用Redis等缓存进行数据校验。

适用操作：

插入，更新，删除

主要流程：

1.服务端提供获取 Token 的接口，客户端调用接口获取 Token，这时候服务端会生成一个 Token 串。

2.服务端将Token串存入 Redis 数据库中，并设置过期时间。

3.将 Token 返回到客户端，客户端在执行提交表单时，把 Token 存入到 Headers 中，执行业务请求带上该 Headers。

4.服务端接收到请求后从 Headers 中拿到 Token，然后根据 Token 到 Redis 中查找该 key 是否存在。

5.服务端根据 Redis 中是否存该 key 进行判断，如果存在就将该 key 删除，然后正常执行业务逻辑。如果不存在就抛异常，返回重复提交的错误信息。