c# – 限制MSMQ消息确定消息的优先级

概述我不确定如何最好地描述这个或最好的标题,所以请耐心等待！ 我正在使用MSMQ排队大量命令,这些命令将触发对各种网站和API的HTTP请求.为了避免锤击这些服务(并保持在某些预定义的请求限制内),我需要确保只有在从最后一个请求开始经过最小时间后才能执行命中同一域的任务. 以前我使用数据库对任务进行排队,因此可以执行查询来实现这一目标,但是我们使用任务数量快速超过了该解决方案(表上的死锁方式太多). 我不确定如何最好地描述这个或最好的标题,所以请耐心等待！

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

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

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

谢谢！

解决方法 你’超过’关系数据库并用MSMQ替换它？这就像从大学到幼儿园的“推动”！ 4GB大小限制,没有高可用性解决方案,可疑的可恢复性,没有查询消息队列,你已经遇到了非常大的限制,而不是每个人在从MSMQ转移到基于关系数据库的队列时声称…

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

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

总结

以上是内存溢出为你收集整理的c# – 限制MSMQ消息/确定消息的优先级全部内容，希望文章能够帮你解决c# – 限制MSMQ消息/确定消息的优先级所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。