接口幂等性

什么是幂等性

接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用；比如说支付场景，用户购买了商品支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额返发现多扣钱了，流水记录也变成了两条．．．,这就没有保证接口的幂等性。

为什么需要实现幂等性？

在接口调用时一般情况下都能正常返回信息不会重复提交，不过在遇见以下情况时可以就会出现问题，如：

• 前端重复提交表单： 在填写一些表格时候，用户填写完成提交，很多时候会因网络波动没有及时对用户做出提交成功响应，致使用户认为没有成功提交，然后一直点提交按钮，这时就会发生重复提交表单请求。
• 用户恶意进行刷单： 例如在实现用户投票这种功能时，如果用户针对一个用户进行重复提交投票，这样会导致接口接收到用户重复提交的投票信息，这样会使投票结果与事实严重不符。
• 接口超时重复提交：很多时候 HTTP 客户端工具都默认开启超时重试的机制，尤其是第三方调用接口时候，为了防止网络波动超时等造成的请求失败，都会添加重试机制，导致一个请求提交多次。
• 消息进行重复消费： 当使用 MQ 消息中间件时候，如果发生消息中间件出现错误未及时提交消费信息，导致发生重复消费。

token机制实现

• 服务端提供了发送token的接口。我们在分析业务的时候，哪些业务是存在幂等问题的，就必须在执行业务前，先去获取token，服务器会把token保存到redis中。
• 然后调用业务接口请求时，把token携带过去，一般放在请求头部。
• 服务器判断token是否存在redis中，存在表示第一次请求，然后删除token,继续执行业务。
• 如果判断token不存在redis中，就表示是重复操作，直接返回重复标记给client，这样就保证了业务代码，不被重复执行。

危险性：

• 先删除token还是后删除token

先删除可能导致，业务确实没有执行，重试还带上之前token，由于防重设计导致，请求还是不能执行。
后删除可能导致，业务处理成功，但是服务闪断，出现超时，没有删除token，别人继续重试，导致业务被执行两边
我们最好设计为先删除token，如果业务调用失败，就重新获取token再次请求。

• Token获取、比较和删除必须是原子性

redis.get(token)、token.equals、redis.del(token)如果这两个操作不是原子，可能导致，高并发下，都get到同样的数据，判断都成功，继续业务并发执行
可以在redis使用lua脚本完成这个操作
if redis.call(‘get’,KEYS[1])==ARGV[1]then return redis.call(‘del’,KEYS[1]) else return 0 end

基于mysql实现

这种实现方式是利用mysql唯一索引的特性。
示意图如下：

具体流程步骤：

• 建立一张去重表，其中某个字段需要建立唯一索引
• 客户端去请求服务端，服务端会将这次请求的一些信息插入这张去重表中，因为表中某个字段带有唯一索引，如果插入成功，证明表中没有这次请求的信息，则执行后续的业务逻辑
• 如果插入失败，则代表已经执行过当前请求，直接返回

基于redis实现

这种实现方式是基于SETNX命令实现的
SETNX key value：将key的值设为value，当且仅当key不存在。若给定的key已经存在，则SETNX不做任何动作。
该命令在设置成功时返回1，设置失败时返回0。
示意图如下：

具体流程步骤：

• 客户端先请求服务端，会拿到一个能代表这次请求业务的唯一字段
• 将该字段以SETNX的方式存入redis中，并根据业务设置相应的超时时间
• 如果设置成功，证明这是第一次请求，则执行后续的业务逻辑
• 如果设置失败，则代表已经执行过当前请求，直接返回

全局请求唯一 id实现

调用接口时，生成一个唯一 id，redis 将数据保存到集合中（去重），存在即处理过。 可以使用 nginx 设置每一个请求的唯一 id；
proxy_set_header X-Request-Id $request_id

其他文档