所以我在设计队列时遇到了很多问题，我收集数据的API应用程序需要调用另一个端点，因此为了避免太多请求，我想将这些请求放入Azure服务总线队列中，但从我了解到的情况来看是更新/插入数据的好方法，但是当涉及到读取数据时，我很难理解如何在处理数据后将处理后的数据返回到前端(UI)。
我想到了当前端请求数据时，我将其放入队列并将消息ID返回到前端，然后在队列中我将使用Azure函数调用我的服务端点，该端点将获取数据并插入到我的数据库中作为 json 有效负载。
请求完成后，我会将请求状态更改为“已完成”，前端将每隔 5-10 秒拉一次检查消息状态，或使用 SignalR 进行实时检查。
还有比我上面提到的更好的解决方案吗？ 我认为它太复杂了，数据冗余可能是一个问题。
提前致谢!
我正在尝试为繁重的获取请求创建一个队列
最佳答案
当发布者发送的消息多于接收者可以处理的消息并且您希望将这两个实体解耦以便接收者不会被请求淹没时，队列特别有用。如果您的目标是减慢到达您正在调用的其他端点的请求数量，同时保持 API 用户继续触发请求的可能性，那么您描述的过程是处理这种情况的标准方法。这是示例图:
假设您的 API 允许用户发布作业，您可以创建一个 UUID 并将其发送回用户/GUI，并将消息排入 Azure 服务总线中。如果您想强制执行 FIFO 处理，请确保 use sessions 。在接收端，您添加一个带有服务总线触发器的 Azure Functions，该触发器调用您的其他端点(您可以通过设置 WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT 来控制 Azure Functions 可扩展的最大实例数，以避免压垮您的其他端点)。如果另一个终结点处理了请求并做出了响应，则可以将结果存储在您选择的数据库中，并将 Azure 服务总线中的消息标记为完成。如果您使用 CosmosDB，则可以利用更改源功能来监听新条目并将其发送到维护与用户的开放连接的 WebSocket 服务器。请记住，WebSocket 连接可能会意外关闭，因此最好为用户提供一个 URI，以便在用户发布作业后查找结果。
关于.net - Azure 服务总线将获取请求添加到队列，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/70729662/