SQL Server Service Broker的缺点

我一直在研究SQL Server Service Broker的范围来替换当前的消息传递解决方案MSMQ.我想知道SQL Server Service Broker的缺点与MSMQ相比,以下标准.

发展

故障排除

性能(假设我们需要每天处理100,000条消息,平均大小约为25 KB)

可扩展性

stuartd.. 34

我在我当前的项目中使用过Service Broker,之前使用过MSMQ(由MassTransit代理)并取得了巨大的成功.我最初对使用Service Broker持怀疑态度,但我不得不承认它的表现非常好.

如果您正在使用发布/订阅模型,那么我每次都会使用消息队列(虽然如果项目允许,我会使用RabbitMQ而不是MSMQ)但是当你只是想要咀嚼一堆数据并将其保存到Sql Server时然后,Service Broker是一个很好的解决方案:事实上,它"接近金属"是一个很大的优势.

发展

Service Broker需要很多样板,这很痛苦,但除非你计划拥有许多不同的队列,否则它是可管理的.Visual Studio中的Sql Server项目需要很多部署的痛苦.

故障排除

Service Broker是一个黑盒子 - 消息进入,它们通常会出现,但如果它们没有,那么故障排除可能会有问题,你所能做的只是查询系统视图 - 有时你根本找不到什么出了问题.这很烦人,但MSMQ也有同样的问题.

性能

Service Broker的表现非常出色.我们每天处理的邮件超过100,000封,SLA负载每小时超过30,000封,我们的邮件大小也很大.我估计在重负载测试期间我们每小时处理近100,000条消息.

为了获得最佳性能我会建议你使用一个对话框池像这样一个 ¹作为创建服务代理对话框可以是一个昂贵的操作.

您还需要使用Remus Rusanu详细介绍的错误处理程序.(如果您确实使用了服务代理,那么您可以在开始之前阅读Remus在该主题上撰写的所有内容,因为您最终将最终阅读它!)

可扩展性

如果需要,您当然可以使用多个服务器进行扩展,但我们没有必要这样做,并且从您提到的负载大小我认为您不需要.

我认为我没有真正设法回答你的问题,因为我没有强调Service Broker队列的足够缺点.我会说其内部工作的难以理解的性质是最令我烦恼的事情 - 当它工作时,它运作良好,但当它停止工作时,很难弄清楚原因.此外,如果队列中有大量消息,则使用ALTER QUEUE需要很长时间才能完成.

不知道你如何使用MSMQ也不同于公平地比较这两种技术.

¹由于原始网址现已"禁用"且页面不在互联网存档中,因此在要点中重新创建.最终在这里找到了一份副本