高响应时间与排队

Question

说我有一个供其他Web服务在内部使用的Web服务，平均响应时间为1分钟。 相对于使请求的服务返回ID，在后台处理请求并使客户端轮询结果，这种具有“同步”响应的服务的优缺点是什么？

HTTP连接是否有任何弊端，它们保持激活状态超过一分钟？默认值是否在这里保持有效？

Answer 1

取决于您的应用程序可能很重要。几件事值得一提！

HTTP协议已同步

人们普遍认为HTTP是异步的。 Http是同步协议，但您的客户端可以异步处理。例如。当您使用http调用任何服务时，您的http客户端可能将调度安排在后台线程上（异步）。但是，http调用将一直等待，直到超时或响应返回为止，在此期间，http调用链一直在同步等待。

套接字

由于HTTP使用套接字，因此套接字有硬限制。每个HTTP连接（如果每次都创建新的连接）都会打开新的socket。如果您一次有数百个请求，则可以镜像同步调度了多少个http调用，并且可以运行套接字。不确定是否要使用其他操作系统，但即使在Windows上使用请求套接字完成操作，它们也不会立即放置并停留几分钟。

网络连接

不建议长时间保持HTTP连接活跃。如果您部分或全部失去网络该怎么办？您的http请求将超时，您将完全不知道其状态。

请牢记所有这些内容，最好在后台进程中安排长时间运行的任务。

Answer 2

如果您在服务器上运行长时间的作业时让用户等待，则说明正在等待时建立有价值的HTTP连接。

从RestFul角度来看，最佳实践是回复HTTP 202（已接受）并返回带有轮询链接的响应。

如果要在等待时挂起客户端，则应在客户端设置请求超时。

如果它们之间有一些防火墙，如果它们在一段时间内处于非活动状态，则可能会断开连接。

Answer 3

响应速度更高

通常，您希望OLTP（Web服务器）尽可能快地响应。由于在后台对任务进行排队，因此Web服务器可以处理更多请求，从而提高了响应吞吐量和处理能力。

更多内存友好

通过消息队列在后台作业上对长时间运行的任务进行排队，可防止滥用Web服务器内存。这很好，因为它将增加应用程序的内存不足阈值。

更能抵抗服务器崩溃

如果您在后台将任务排队，并且出现问题，则可以将该作业排队到死信队列中，这将帮助您最终解决问题并重新处理导致未处理异常的请求。