限制MSMQ消息/确定消息的优先级

Question

我不确定如何最好地描述这个或最好的标题，所以忍受我！

我正在使用MSMQ排队大量命令，这些命令将触发对各种网站和API的HTTP请求。为了避免锤击这些服务（并保持在某些预先定义的请求限制内），我需要确保只有在从最后一次请求开始经过最小时间后才能执行命中同一域的任务。

以前我使用数据库对任务进行排队，因此可以执行查询来实现这一目标，但是我们使用任务数量快速超过了该解决方案（表上的死锁方式太多）。

有没有人对我们采取什么方法有任何建议？我已经考虑过将项目从队列中删除，直到找到一个可以执行的项目 - 但是我意识到没有什么可以阻止队列上的排序，这意味着我们可以在同一个域中取出数千个，然后再找到一个域。

谢谢！

Answer 1

嗯，我完全不同意Remus Rusanu的回答。

MSMQ绝不是数据库表中的一个步骤，并且在许多方面可以是一个升级，如果您需要它们，您需要手动构建基于表的解决方案。

请参阅MSMQ v Database Table

在说，根据您的要求，数据库表似乎是最合适的。

MSMQ适用于您不拥有的应用之间的通信 如果您不需要立即结果，并需要可靠的交付 （即，您可以在与DB断开连接时使用MSMQ，而使用表方法则需要数据库访问。） MSMQ可以进行负载均衡

Answer 2

您'超过'关系数据库并将其替换为MSMQ？这就像从大学到幼儿园的“推动”！ 4GB大小限制，没有高可用性解决方案，可疑的可恢复性，没有查询消息队列，当你将从 MSMQ移动到基于关系数据库的队列时，你已经遇到了非常大的限制。 ..

我强烈建议你回到基于表的排队。有一些方法可以避免基于表的队列中的死锁，特别是DELETE的OUTPUT子句的出现（这是从基于表的队列中编写快速死锁自由队列操作的关键）。

或者您可以使用现成的数据库排队解决方案，如Service Broker。实际上，SSB将提供免费午餐，其中包含许多功能，例如内置限制（MAX_QUEUE_READERS），按计划启用/禁用处理（通过启用/禁用激活），built-in timers进行重试，高 - 基于数据库镜像或群集的可用性，或built-in priority handling。