我刚刚开始研究 Tornado 和异步网络服务器。在 Tornado 的许多示例中，较长的请求是通过以下方式处理的:
- 调用tornado网络服务器
- tornado 对 api 进行异步网络调用
- 让tornado在回调等待调用时继续接受请求
- 处理回调中的响应。服务器到用户。
因此，出于假设目的，假设用户正在 /retrive 向tornado 服务器发出请求。 /retrieve 将向内部 api myapi.com/retrieve_posts_for_user_id/ 或 w/e 发出请求。 api 请求在获取请求时可能需要一秒钟才能运行，然后当它最终返回 Tornado 服务器响应时。 首先，这个流程是使用 Tornado 的“正常”方式吗？网上的许多代码示例都会这么建议。
其次，(这是我开始困惑的地方)假设上述流程是标准流程，myapi.com 应该是异步的吗？如果它不是异步的并且每个请求可能需要几秒钟，那么它是否会产生与阻塞服务器相同的瓶颈？也许 Tornado 或任何异步的正常用例的示例将有助于阐明这个问题？谢谢。
最佳答案
是的，据我了解您的问题，这是 Tornado 的正常用例。
如果对 Tornado 服务器的所有请求都会向 myapi.com 发出请求，并且 myapi.com 被阻止，那么是的，myapi.com code> 仍然是瓶颈。然而，如果只有一些请求需要由 myapi.com 处理，那么 Tornado 仍然会胜出，因为它可以在等待对 myapi.com 请求的响应时继续处理此类请求。 com。但无论如何，如果 myapi.com 无法处理负载，那么在其前面放置 Tornado 服务器并不能神奇地解决这个问题。不同之处在于，即使 myapi.com 繁忙，您的 Tornado 服务器仍然能够响应请求。
关于python - Tornado/异步 Web 服务器理论，如何处理长时间运行的操作以利用异步服务器，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10246539/