异步调用和响应之间的最长时间（Web 服务）

Question

是否有任何最佳实践规定了异步调用与其相应响应之间的最长时间。

基本上我有一个需要很长时间才能运行的进程（例如：5 分钟）。 选项 1： 我可以将进程公开为异步调用。在这种情况下，用户调用我的服务，然后在稍后的某个时间，我以进程状态响应。

选项 2 我可以实现它的另一种方法是设置系统，以便在我的 Web 服务上进行单向操作，该操作开始该过程并立即返回该过程的 ID。然后我可以强制消费者提供单向操作，我可以在流程完成后调用并报告。

第一个选项更容易，因为我不必要求调用者做任何事情。第二个似乎更好，因为我可以随时报告（5 分钟到几年后）。

由于我可以完全控制调用方及其内部可用服务，因此我倾向于选项 2。

所以我想知道异步调用是否有任何时间限制（它们可以跨越数天吗？如果不是最佳做法是什么）。选项 2 是采用的标准模式吗？

引用将非常有用。

Answer 1

选项 #2 更好，因为它更受事件驱动。

但是，存在选项 #3。客户端向服务器发出请求。服务器将请求排队并以 id 响应。客户端每隔一段时间检查一次，传递请求 id，看看它是否已完成。

这样您就不必依赖于请求完成时客户端是否可用。

我可能会混合使用 #2 和 #3 选项，让客户选择他们是否希望在他们身边触发事件，或者他们只是想稍后再回来查看。

更新
Rajah 询问了异步请求和响应之间的最长时间。对于 WEB 应用程序，这通常以秒为单位。大多数服务器的超时值通常默认在 30 秒范围内。就个人而言，我认为这太长了。

考虑到异步调用要求客户端和服务器之间的通信通道在此期间保持打开状态。单个服务器可以处理多少个通道？更重要的是，在提出请求时，您需要维护多少个频道？即使你控制了两端，这也会变得非常离谱。

托管您的服务的任何内容都将决定保持请求打开的最长时间。同样，我见过的每台服务器都可以在几秒钟内测量到这一点。