问题描述
我一直在研究SQL Server Service Broker的范围，以替换当前的消息传递解决方案MSMQ.我想知道与MSMQ相比，SQL Server Service Broker的劣势.
I have been doing r&d for the scope of SQL Server Service Broker to replace current messaging solution MSMQ. I want to know disadvantages of SQL Server Service Broker in contrast to MSMQ for following criteria.
- 发展
- 故障排除
- 性能(假设我们每天需要处理100,000条消息，平均大小约为25 KB)
- 可扩展性
推荐答案
我在当前的项目中使用Service Broker，之前使用过MSMQ(由 MassTransit )，获得了巨大的成功.最初，我对使用Service Broker表示怀疑，但我必须承认它的表现非常出色.
I've used Service Broker in my current project, having previously used MSMQ (brokered by MassTransit) with great success. I was initially dubious about using Service Broker, but I have to admit it has performed very well.
如果您使用的是发布/订阅"模型，那么我将每次都使用消息队列(尽管如果项目允许，我将在MSMQ上使用RabbitMQ)，但是当您只想检查一堆数据并将其持久化时对于Sql Server来说，Service Broker是一个很好的解决方案:它是如此接近金属"是一个很大的优势.
If you're using the Publish / Subscribe model, then I would use Message Queueing every time (though I would use RabbitMQ over MSMQ if the project allowed) but when you just want to chew through a stack of data and persist it to Sql Server, then Service Broker is a great solution: the fact it's so 'close to the metal' is a big advantage.
发展
Service Broker需要很多样板，这很痛苦，但是除非您计划有许多不同的队列，否则它是可管理的. Visual Studio中的Sql Server项目要花很多时间去部署.
Service Broker requires a lot of boilerplate, which is a pain, but unless you're planning on having lots of different queues it's manageable. Sql Server projects in Visual Studio take a lot of the pain of deploying away.
问题排查
Service Broker是一个黑匣子-消息进入后通常会发出，但如果不发送，则故障排除可能会成问题，而您所能做的就是查询系统视图-有时您根本无法找出问题所在.这很烦人，但是MSMQ有同样的问题.
Service Broker is a black box - messages go in, and they usually come out, but if they don't then troubleshooting can be problematic, and all you can do is query the system views - and sometimes you simply can't find out what has gone wrong. This is annoying, but MSMQ has the same kind of issues..
性能
Service Broker的性能非常好.我们每天要处理超过100,000条消息，在SLA负载下每小时要处理超过30,000条消息，并且消息量很大.我估计在重负载测试期间，每小时我们将处理近100,000条消息.
Service Broker performance is excellent. We are processing a lot more than 100,000 messages per day, more than 30,000 per hour at our SLA load, and our message sizes are large. I would estimate we process close to 100,000 messages per hour during heavy load testing.
为了获得最佳性能，我建议您使用一个此对话框的对话框池. 1 作为创建Service Broker对话框的可能是一项昂贵的手术.
For best performance I would advise you to use a Dialog Pool like this one as creating a Service Broker dialog can be an expensive operation.
您还将希望使用错误处理雷木斯·鲁萨努(Remus Rusanu)详细介绍的程序. (如果您确实使用Service broker，则不妨在开始之前阅读Remus在该主题上写的所有内容，因为最终最终还是会阅读它！)
You will also want to use the Error Handling procedures detailed by Remus Rusanu. (If you do use Service broker, you might as well read everything Remus has written on the subject before you start, as you'll end out reading it eventually!)
可扩展性
如果需要，您当然可以使用多个服务器来进行扩展，尽管我们不必这样做，并且从负载大小中提到，我认为您也不需要.
You can certainly use more than one server to scale up if required, though we haven't had to do so, and from the load size you mention I don't think you would need to either.
我认为我没有真正回答您的问题，因为我没有强调Service Broker队列的不足之处.我要说的是，其内部运作的坚不可摧的本质是令我最烦的一件事-当它运行时，它会很好地工作，但是当它停止工作时，很难弄清楚为什么.另外，如果队列中有很多邮件，则使用ALTER QUEUE会花费很长的时间.
I don't think I have really managed to answer your question, as I haven't highlighted enough disadvantages of Service Broker queues. I would say the impenetrable nature of its internal workings is the thing that most annoys me - when it works, it works very well, but when it stops working it can be very hard to figure out why. Also, if you have a lot of messages in a queue, using ALTER QUEUE takes a very long time to complete.
不知道您如何使用MSMQ，也很难公平地比较这两种技术.
Not knowing how you are using MSMQ also makes it different to fairly compare the two technologies.
根据要点重新创建为原始网址，并且该页面不在Internet存档中.最终在此处
Recreated in a gist as the original url is now "disabled" and the page isn't in the internet archive. Eventually found a copy here
这篇关于SQL Server Service Broker的缺点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！