同时管理多个Azure服务总线队列
我正在使用Azure环境并在其中开发。网的
我正在运行一个web应用程序（ClientApp），它获取客户端数据以执行一系列计算。这些计算是性能密集型的，因此它们在单独的web应用程序（CalcApp）上运行。
当前，ClientApp将计算请求发送给CalcApp。来自每个客户机的请求被放入一个公共队列中，并一次运行一个，即FIFO。我的目标是为每个客户机创建单独的队列，并同时运行多个计算。
我正在考虑使用Azure服务总线队列来实现这一点。在ClientApp上，服务总线将检查该客户端的现有队列，并在需要时创建一个队列。在CalcApp上，应用程序会定期检查现有队列。如果它找到一个新的队列，那么它将创建一个新的QueueClient，它使用OnMessageAsync（）和RunCompationsAsync（）作为回调函数。
这是可行的还是好主意？
共有1个答案
我会考虑使用多个消费者，也许有一个主题表示“客户端”，如果您需要区分基于客户端的处理类型。每个客户机都可以向队列中添加一个条目，而消费者会为消息“争斗”。如果采用这种方法，则同一消息不可能被处理两次。
我不确定是否需要多个队列。
下面是关于竞争消费者模式的更多信息
https://msdn.microsoft.com/en-us/library/dn568101.aspx
您还可以构建一个使用者并生成多个线程。在这个模型中，您将有一个队列和一个消费者，但仍然能够一次计算多个。不过，最终，竞争对手的消费者更具可扩展性，可以使用这两种策略的组合。
-
我正在使用azure服务总线主题和订阅机制，并希望处理所有在死信队列中的消息。 此外，我想通过C#中的Azure Web作业处理消息，并将其发送回队列。所以我想知道如何通过我的应用程序处理死信队列上的消息？
-
我有一个服务总线Q，从Azure门户可以或多或少地看到服务总线Q包含多少条目。如何使用他们的管理API获取此计数？我仔细阅读了文档，但没有找到答案。
-
今天晚上，我们观察到排队时间非常慢。我们的追踪数据告诉我们 需要45-60秒。这种情况发生在两个已经存在很长时间的队列上。他们几乎从来没有超过1-2条记录，我们使用一个带有服务总线触发器的网络作业来完成任务。我们正在排队等候一个简单的POCO。还有另一个队列正在快速排队，所以由于没有任何其他想法，我删除了两个麻烦的队列。当代码重新创建它们时（正如它被构建时所做的那样），它们在不到一秒钟的时间里开始
-
但是，问题还是出现了。我唯一的猜测是，当调用时，同一个实例再次拾取消息？ 我想我真正想问的是，如果我有一个主题订阅客户端的多个实例都指向该主题的同一个订阅者，那么所有实例是否都有可能获得消息的副本？还是不保证。
-
一旦部署到云，我无法从Azure网站访问Azure服务总线队列。在localhost上运行时，如果工作正常，我可以向队列发送消息，但如果我部署应用程序，在远程服务器上创建QueueClient时会出现异常： “套接字连接被中止，因为对套接字的异步发送未在分配的超时00:00:59.4820817内完成。分配给此操作的时间可能是更长超时的一部分。” 我正在使用QueueClient。CreateFr
-
使用WebJobs SDK时，将代理消息移动到死信队列的正确方法是什么？通常我会打电话给味精。死信（）。但是，SDK负责管理代理消息的生命周期。它将调用msg。如果方法返回成功，则返回Complete（），如果发生异常，则将重试该消息。我需要第三种情况，告诉ServiceBus队列将消息移动到死信队列，因为它是一条坏消息。