接口超时-千篇一律的重试和优化

我以为我当甲方爸爸了，结果作为一个程序员在哪里工作能拿出甲方爸爸的硬气来呢？别个是真的不重视啊。调用别人接口，有问题别人是真不回啊，一个问题用了一天解决？

接口超时了，半分钟的超时时间都没够用

半分钟的接口超时时间都没够用，依然超时了。建议我们调成1分钟。

讲道理，我一共也没传超过10条数据啊，为什么要这样折磨我。

搜一下接口超时解决方案

都建议我重试，优化接口。

首先，接口是别个的，我能优化个啥？

其次，重试这操作并不适合所有操作，一般查询接口重试还勉强合理，其他的可就不怎么符合业务了。

创建型的业务，不适用重试，虽然接口超时了，但是实际上在对方的系统操作是成功了。结果我们重试，直接报错数据重复了。这样结果就是我们系统认为这个事失败了，但是实际上成功了。

还好我们业务可以人工介入处理，失败了就直接转人工核实就OK了。

解决方式思考：

我思考，接口超时，首先是要考虑不同场景的，不同场景有不同的策略。

像这种创建型业务，我理解解决方式三种：

一：改变交互方式，请求接口后，不进行实时结果的等待。通过监听消息中间件的方式，对方处理结束后发消息到消息中间件。

二：对方提供查询接口，可以通过查询方式，进行数据核验，纠正本地数据结果。这个是我瞎编的，不怎么理想。

三：让对方优化接口性能

大家都是如何解决和外部公司接口对接超时的问题的呢？