发起HTTP请求时：等待任务完成还是接收回调请求？

一、等待任务完成后返回状态码 #

• 好处：流程简单直接，调用方不用额外写回调逻辑，看响应状态码就知道结果
• 问题：
  • 大概率触发HTTP超时：不管是客户端还是服务器，默认超时时间一般都远短于5分钟，到点请求直接失败，你根本拿不到真实的任务结果
  • 浪费连接资源：请求挂着的几分钟里，一直占着HTTP连接，并发高的时候服务器连接池很容易被耗尽，其他请求就没法处理了
  • 容错差：中间要是网络断一下，你完全不知道任务到底成没成，连个反馈都没有

二、任务单独回发请求告知结果（异步回调） #

• 好处：
  • 彻底避免超时：触发任务后服务器立刻返回202 Accepted，表示任务已经接收到正在处理，你不用傻等
  • 省资源：HTTP连接用完就释放，不会占着坑位影响其他请求
  • 靠谱性高：就算中间网络波动，回调可以加重试机制，保证你能收到结果通知
• 问题：
  • 你得提前准备好一个能被服务器访问到的回调接口，还要写接收结果的逻辑
  • 要防重复通知：比如任务重试可能会发多次回调，得用任务ID做幂等校验，避免重复处理

怎么选？ #

如果任务最多30秒，而且你能把客户端和服务器的超时时间都调到对应长度，同时并发量很低，那第一种方案勉强能用。但只要任务可能跑到5分钟，优先选异步回调，这也是行业里处理长耗时任务的常规操作。

另外还有个折中办法：触发任务后服务器返回一个任务ID，你自己写个逻辑定期去查这个任务的状态。这种不用回调接口，但得主动查，适合没法提供回调接口的场景，不过并发高的话，频繁轮询会给服务器加不少压力。

内容的提问来源于stack exchange，提问作者Souf149