我应该使用MSMQ或SQL Service Broker进行交易吗？

Question

我的团队负责人已经要求我调查MSMQ作为我们产品新版本的选项.我们在当前版本中使用SQL Service Broker.我已经完成了相当多的实验和谷歌搜索,以找到哪个产品更符合我的需求,但我想我会问我最熟悉的网站来编程答案.

一些细节:

• 我们的客户端是.NET 1.1和2.0代码; 这是消息发送的地方.
• SQL Server 2005实例中的目标.所有消息最终都是数据库更新或插入.
• 我们将发送几个必须被视为交易的更新.
• 我们必须拥有完美的消息可恢复性; 没有消息可以丢失.
• 即使目标SQL服务器关闭,我们也必须是异步的并且能够接受消息.
• 开发我们自己的排队解决方案不是一种选择; 我们是一个小团队.

到目前为止我发现的事情:

• MSMQ和SQL Service Broker都可以完成这项工作.
• 对于事务性消息来说,服务代理似乎更快.
• Service Broker需要在某处运行SQL Server,而MSMQ需要在任何地方运行任何已配置的Windows机器.
• MSMQ似乎更好/更快/更容易在群集中设置/运行.

我错过了什么吗？这里有明显的赢家吗？任何想法,经验或链接都会受到重视.谢谢!

编辑:我们最终坚持使用服务代理,因为我们的一些客户端代码中使用了自定义数据库框架(我们更好地处理事务).该代码捕获了事务的SQL,但没有.客户端代码也是.NET的1.1版本,因此我们必须升级所有客户端代码.谢谢你的帮助!

Answer 1

刚刚将我的应用程序从Service Broker迁移到MSMQ,我将不得不投票使用MSMQ.有几个因素需要考虑,但其中大部分都与您使用数据的方式和处理方式有关.

• 如果在数据库中完成处理？服务经纪人
• 如果只是数据移动？服务经纪人
• 处理是在.NET/COM代码中完成的吗？MSMQ
• 您是否需要远程分布式事务(例如,在不同于SQL的框上进行处理)？MSMQ
• 您是否需要能够在目的地关闭时发送消息？MSMQ
• 你想使用nServiceBus,MassTransit,Rhino-ESB等吗？MSMQ

无论你选择什么,都要考虑的事情

• 你怎么知道队列的健康状况？这两个选项都以不同方式处理故 例如,Service Broker将在某些可能导致您的应用程序关闭的情况下禁用您的队列.
• 你将如何进行报道？如果您已经在报表中使用SQL表,那么Service Broker可以很容易地适应,因为它只是另一个动态表.如果您已经在使用性能监视器MSMQ可能更适合.Service Broker确实有很多性能计数器,因此不要让它成为您唯一的因素.
• 你如何衡量正常运行时间？它只是确保您不会丢失交易,还是需要同步响应？我发现MSMQ的分布式特性允许更长的正常运行时间,因为主队列可以脱机而不会丢失任何东西.而对于Service Broker,您的数据库必须在线,否则您将失败.
• 您是否已经拥有这些技术之一的经验？两者都有很多实现细节可以回来咬你.
• 无论您做出何种选择,切换底层排队技术有多容易？我建议您使用一个通用的IQueue接口来编写具体的实现.这样,如果您发现错误的选择,您可以在以后轻松更改您所做的选择.毕竟,队列只是一个队列,不应该将您锁定到特定的实现中.