>发展
>疑难解答
>性能(假设我们需要每天处理10万条消息,平均大小在25 KB左右)
>可扩展性
解决方法
如果您使用Publish / Subscribe模式,那么我每次都会使用Message Queuing(尽管如果项目允许,我会使用RabbitMQ超过MSMQ),但是当您只想通过一堆数据咀嚼数据并将其持久保存到sql Server那么服务经纪人是一个很好的解决方案：事实上,它是如此“靠近金属”是一个很大的优势.
发展
服务经纪人需要大量的样板,这是一个痛苦,但除非你打算拥有很多不同的队列才能管理. Visual Studio中的sql Server项目需要很大的部署时间.
故障排除
服务经纪人是一个黑盒子 – 消息进来,他们通常会出来,但如果他们没有,那么故障排除可能是有问题的,所有你可以做的是query the system views – 有时你根本找不到出了什么问题.这很烦人,但MSMQ有同样的问题.
服务经纪人表现非常出色.我们正在处理每天超过10万条消息,在我们的SLA负载下每小时超过30,000次,我们的邮件大小很大.我估计在重负载测试期间,我们每小时处理接近10万条消息.
为了获得最佳性能,我建议您使用像this one这样的对话框来创建一个Service Broker对话框can be an expensive operation.
您也将使用the Error Handling procedures detailed by Remus Rusanu.(如果您使用服务经纪人,您可以先阅读Remus在开始之前写过的所有主题,最终结束阅读！)
可扩展性
如果需要,您可以使用多个服务器进行扩展,尽管我们没有这样做,并且从您提到的加载大小来看,我不认为您也需要.
我不认为我真的设法回答你的问题,因为我没有强调服务代理队列的足够的缺点.我会说,内部运作的不可穿透的性质是最让我感到厌烦的事情 – 它的工作原理很好,但是当它停止工作时,很难找出原因.另外,如果队列中有很多消息,使用ALTER QUEUE需要很长时间才能完成.
不知道你如何使用MSMQ也使得它们不同于对这两种技术进行比较.
