sql-server – SQL Server服务代理的缺点

我一直在研究sql Server服务代理的范围来替代当前的消息传递解决方案MSMQ.我想知道sql Server Service broker的缺点,与MSMQ相反,以下标准.

>发展
>疑难解答
>性能(假设我们需要每天处理10万条消息,平均大小在25 KB左右)
>可扩展性

解决方法

在我目前的项目中,我已经使用过Service broker,以前使用过MSMQ(由 MassTransit进行的),取得了巨大的成功.我最初对使用Service broker有疑虑,但我不得不承认它表现非常好.

如果您使用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也使得它们不同于对这两种技术进行比较.