我还没有理解 Web 服务器线程的行为，如果我对数据库进行异步调用，并立即向客户端返回响应（说 OK），甚至无需等待异步调用返回。首先，这是一个好方法吗？进行异步调用的线程会发生什么，如果它再次用于服务另一个请求，然后之前的异步调用返回到这个特定的线程。或者网络服务器是否让这个线程等待它发出的异步调用返回。然后问题将是许多挂起的线程将打开，并且 Web 服务器将可用于接受更多请求。我正在寻找答案。
【问题讨论】：
标签： http asynchronous request webserver response
这取决于您的 HTTP 服务器的工作方式。但是你应该非常谨慎。
假设您有一个处理传入 HTTP 连接的主事件循环，以及管理 HTTP 通信的工作线程。 只有当工作线程有效地完全准备好接受新的 HTTP 请求管理时，它才应被视为已准备好接受新的 HTTP 请求管理。
就纯 HTTP 而言，更重要的是避免在收到整个查询之前发送响应。这看起来很简单，而且通常都是这样。但是如果查询作为一个主体，可能是一个分块的主体，那么接收整个消息可能需要一些时间。 您应该从不之前发送响应，除非它类似于 400 错误请求响应，然后是真正的 tcp/ip 连接关闭。如果您没有这样做，并且您遇到消息长度解析问题，那么您在查询结束之前发送响应的事实可能会导致安全问题。在某种 http 走私问题中，它可用于利用服务器与服务器前面的任何其他 HTTP 代理（ssl 终结器、反向代理等）之间的消息解析差异。对于这个代理来说，如果你做出了回应，就意味着你已经掌握了整个消息，它可以发送下一条消息，你实际上会认为这只是正文的另一部分。
现在，如果您有完整的消息，您可以决定发送早期响应并分离异步任务以真正执行某种东西。但这意味着：
因此，您开始进入一个您应该了解 HTTP 服务器内部结构的区域，该区域可能由您管理，也可能不由您管理，并且迟早会出现更改。然后你开始制作非常奇怪的东西，这通常会导致奇怪的问题，难以重现。
通常处理异步任务的最佳方式是使用消息系统，同时仍能理解发生了什么。将任务列表放入queue，并获得一个并行异步工作进程，它会处理这些任务。如果需要，跟踪这些任务的状态。 同样的事情也适用于客户端，在收到一个非常快的 HTTP 应答后，它可能需要对任务状态执行一些 ajax 状态轮询。您可能只需要检查队列中任务的状态即可发送响应。
您将对整个事情有更多的控制权。
对我来说，我真的不喜欢分离的线程、来自奇怪的代码、执行繁重的任务而没有任何输出状态或报告错误的方式，并且可能会阻止漂亮的应用程序停止调用（仍在等待奇怪的线程加入）并不意味着杀戮。
【讨论】：
这取决于此异步操作是否执行应通知客户端的操作。
如果您返回 200 OK（即成功完成）并且稍后异步操作失败，则客户端将不知道错误。
您当然有一些选项，例如通过 websocket 发送某种推送通知或发送另一个请求，该请求将返回实际结果等。所以基本上取决于你的需求...
【讨论】：