面试官：接口超时，到底如何处理

导语：

当前互联网的系统几乎都是解耦隔离后，会存在各个不同系统的相互远程调用。调用远程服务会有三个状态：成功，失败，或者超时。前两者都是明确的状态，而超时则是未知状态。我们转账超时的时候，如果下游转账系统做好幂等控制，我们发起重试，那即可以保证转账正常进行，又可以保证不会多转一笔。所以掌握幂的用法非常重要！

正文

大家好，我是程序员田螺。今天我们一起来聊聊幂等设计。

• 什么是幂等
• 为什么需要幂等
• 接口超时，如何处理呢？
• 如何设计幂等？
• 实现幂等的8种方案
• HTTP的幂等

1. 什么是幂等?

幂等是一个数学与计算机科学概念。

在数学中，幂等用函数表达式就是：f(x) = f(f(x))。比如求绝对值的函数，就是幂等的，abs(x) = abs(abs(x))。
计算机科学中，幂等表示一次和多次请求某一个资源应该具有同样的副作用，或者说，多次请求所产生的影响与一次请求执行的影响效果相同。

2. 为什么需要幂等

举个例子：
我们开发一个转账功能，假设我们调用下游接口超时了。一般情况下，超时可能是网络传输丢包的问题，也可能是请求时没送到，还有可能是请求到了，返回结果却丢了。这时候我们是否可以重试呢？如果重试的话，是否会多转了一笔钱呢？

转账超时

当前互联网的系统几乎都是解耦隔离后，会存在各个不同系统的相互远程调用。调用远程服务会有三个状态：成功，失败，或者超时。前两者都是明确的状态，而超时则是未知状态。我们转账超时的时候，如果下游转账系统做好幂等控制，我们发起重试，那即可以保证转账正常进行，又可以保证不会多转一笔。

其实除了转账这个例子，日常开发中，还有很多很多例子需要考虑幂等。比如：
MQ（消息中间件）消费者读取消息时，有可能会读取到重复消息。（重复消费）
比如提交form表单时，如果快速点击提交按钮，可能产生了两条一样的数据（前端重复提交）

3. 接口超时了，到底如何处理？

如果我们调用下游接口超时了，我们应该怎么处理呢？
有两种方案处理：

• 方案一：就是下游系统提供一个对应的查询接口。如果接口超时了，先查下对应的记录，如果查到是成功，就走成功流程，如果是失败，就按失败处理。

拿我们的转账例子来说，转账系统提供一个查询转账记录的接口，如果渠道系统调用转账系统超时时，渠道系统先去查询一下这笔记录，看下这笔转账记录成功还是失败，如果成功就走成功流程，失败再重试发起转账。

• 方案二：下游接口支持幂等，上游系统如果调用超时，发起重试即可。‘

两种方案都是挺不错的，但是如果是MQ重复消费的场景，方案一处理并不是很妥，所以，我们还是要求下游系统对外接口支持幂等。

4. 如何设计幂等

既然这么多场景需要考虑幂等，那我们如何设计幂等呢？

幂等意味着一条请求的唯一性。不管是你哪个方案去设计幂等，都需要一个全局唯一的ID，去标记这个请求是独一无二的。

• 如果你是利用唯一索引控制幂等，那唯一索引是唯一的
• 如果你是利用数据库主键控制幂等，那主键是唯一的
• 如果你是悲观锁的方式，底层标记还是全局唯一的ID
• 4.1 全局的唯一性ID

全局唯一性ID，我们怎么去生成呢？你可以回想下，数据库主键Id怎么生成的呢？

是的，我们可以使用UUID，但是UUID的缺点比较明显，它字符串占用的空间比较大，生成的ID过于随机，可读性差，而且没有递增。

我们还可以使用雪花算法（Snowflake