Azure服务总线将get请求添加到队列中

Question

因此，我在解列队列方面有如此大的问题，我收集数据的API应用程序需要调用另一个端点，因此为了避免过多的请求，我想将这些请求放入Azure服务总线队列中，但据我所知，这是更新/插入数据的好方法，但当涉及到读取数据时，我很难理解如何在处理数据后将处理过的数据返回到前端(UI)。

我想出了这样的想法:当前端请求数据时，我将其放入队列并将消息id返回到前面，然后在队列中使用Azure函数调用我的服务端点，它将获取数据并作为json有效载荷插入到我的数据库中。

一旦请求已经完成，我将更改请求状态为复杂和前端将做拉检查消息状态每5-10秒或使用SignalR进行实时检查。

有比我前面提到的更好的解决方案吗？我认为它过于复杂和数据冗余可能是一个问题。

提前感谢！

我试图为大量的get请求创建一个队列。

Answer 1

当发布者发送的消息比接收者所能处理的消息更多时，队列尤其有用，并且您希望将这两个实体解耦，这样接收方就不会被请求淹没。如果您的目标是减缓访问正在调用的另一个端点的请求数量，同时保持API用户继续触发请求的可能性，那么您所描述的过程是处理此场景的标准方法。下面是一个示例说明：

假设您的API允许用户发布作业，则创建一个UUID并将其发送回用户/GUI，并在Azure服务总线中对消息进行排队。如果要执行FIFO处理，请确保使用使用会话。在接收端，添加带有服务总线触发器的Azure函数，该触发器调用另一个端点(您可以通过设置输出来控制Azure函数可以扩展到的实例的最大数量，以避免压倒其他端点)。如果另一个端点处理请求并作出响应，则将结果存储在您选择的数据库中，并在Azure服务总线中将消息标记为完整。如果使用CosmosDB，则可以利用变更提要功能侦听新条目，并将它们发送到WebSocket服务器，该服务器维护与用户的开放连接。请记住，WebSocket连接可能会意外关闭，因此，当用户发布作业时，给他们一个URI来查找结果可能是个好主意。

Answer 2

web请求本质上是一种同步操作。持久消息传递是异步的。将两者结合起来需要弥合差距，这从来就不是一件小事。轮询是不理想的，因为越来越多的客户端，它将对您的web服务器征税。SignalR是一个更好的选择，可以回调需要知道结果的特定客户机。

这种解决方案的另一面是以更新或计算结果最终而不是即时的方式构建客户端。