推迟阻止Rails请求

        对于长请求，我有一个类似的问题，该请求会阻止工人接受其他请求。所有Web应用程序都有问题。甚至Node.js可能也无法解决在工作人员身上花费过多时间的问题，或者可能只是耗尽内存。 我研究的Web应用程序具有一个Web界面，该界面将请求发送到Rails REST API，然后Rails控制器必须请求运行大量耗时任务的Node REST API来获取一些数据。从Rails到Node.js的请求可能需要2-3分钟。 我们仍在尝试找到不同的方法，但是以下方法可能对您有用，或者您可以调整一些想法，我也希望得到一些反馈： 前端在同一会话中使用生成的标识符[A]向Rails API发送请求。 （此标识符有助于识别来自同一用户会话的先前请求）。 Rails API将前端请求和标识符[A]代理到Node.js服务 Node.js服务将此作业添加到队列系统（例如RabbitMQ或Redis），消息中包含标识符[A]。 （在这里，您应该根据自己的情况考虑，还假设系统将消耗队列作业并保存结果） 如果再次发送相同的请求，则根据要求，您可以杀死具有相同标识符[A]的当前作业，并计划/排队最近的请求，或者忽略等待第一个请求完成的最新请求，或其他决定符合您的业务需求。 前端可以发送间隔REST请求，以检查标识为[A]的数据处理是否已完成，那么这些请求是轻量级且快速的。 Node.js完成工作后，您可以使用消息订阅系统，也可以等待下一个即将出现的检查状态“请求”并将结果返回到前端。 您还可以使用负载均衡器，例如亚马逊负载均衡器Haproxy。 37signals的博客文章和视频介绍了如何使用Haproxy卸载一些长时间运行的请求，这些请求不会阻止较短的请求。 Github使用类似的策略来处理长时间的请求，以生成提交/贡献可视化。他们还设置了拉动时间的限制。如果时间太长，Github会显示一条消息，说时间太长并且已被取消。 YouTube对于长时间排队的任务有一个很好的信息：“这比预期的时间长。您的视频已经排队，将尽快得到处理。” 我认为这只是一个解决方案。您还可以看一下EventMachine gem，它有助于提高性能，处理程序并行或异步请求。 由于这种问题可能涉及一项或多项服务。如果缓存可能有帮助，请考虑提高那些服务（例如数据库，网络，消息协议等）之间的性能的可能性，尝试缓存频繁的请求或预先计算结果。