【问题记录】【请求方式选择】GET 方式的请求一次却产生三次请求

1  问题现象

今儿客户反应账户余额导出的有问题，我就去看了看，首先我看了下导出的文件，余额都是0，我就去数据库看了下，有很多余额都不是0，说明导出确实有问题，我就看了下代码，发现代码逻辑上确实存在一定的问题，逻辑修了修，然后测试一下。

因为这个导出首先是 GET 方式的请求，然后还是同步的，你比如倒个全量的，他就是要等都导出后才给你结果（唉，我都不想吐槽这些人写的这代码）。我们说重要问题，同步的话，几十万的信息，势必会导致超时。但是我测试的时候，发现我请求一次，日志里的 controller 却打印了三次，一开始我还以为是别人也在导出，但是我测了几次，发现就是每次请求他都会打印三次，并且每次的间隔还是60秒。

这个问题跟我之前的这篇有点像，【OpenFeign 】OpenFeign 下未开启重试，服务却被调用了两次，我就寻思，是不是我们的 ingress 里配了这种重试呢，找了一下没有配置，是不是代码里有这种重试逻辑呢？发现也没有。

陷入纳闷，不可能是前端有这种逻辑吧，然后我本地用 Postman 调用了一下，还是打印了三次，说明不是人家前端的问题。

是Postman、或者浏览器这种客户端重试的么？那他们的请求日志也应该能捕获到，但是通过 Wireshark抓包，发现还是只请求了一次，我觉得还是 ingress 有重试，然后这个我问了阿里云的人，他们的 ingress 默认自带超时重试，并且重试3次，超时时间是60秒，这就跟日志打印的现象有点符合了。

另外在排查的时候，发现的一个现象，导致我的误判，就是我刚开始用 Postman 调用接口的时候，我请求完，会有个取消请求的按钮，如下，当我点了这个取消的按钮，请求日志就会只有一次，不点的话，就会有三次，我就以为是 Postman、浏览器这种客户端，对于 GET 请求会有默认重试的机制= =，就会有这样的错觉，其实不是，当点击玩取消其实就相当于结束会话，断开连接了，下边的请求捕获可以看到，点击完取消，就会发送一个 FIN 信号了，表示断开连接，连接都断开了，ingress 就不会重试了。

2  解决办法

（1）直接加了一个 POST 方式的 Mapping，然后让前端改成 POST 方式的即可。

（2）更改 ingress 的超时时间：

nginx.ingress.kubernetes.io/proxy-read-timeout: "300"
nginx.ingress.kubernetes.io/proxy-send-timeout: "300"

另外这种大批量导出，一定要异步，不要像我们公司这样还同步，唉，写的啥都。

好啦，这个问题就记录到这里，有点意思，有理解不对的地方，欢迎指正。