MSMQ v数据库表

Question

现有流程会更改表格中预订记录的状态字段，以响应用户输入。

我有另一个要编写的进程，它将为具有特定状态的记录异步运行。它将读取表记录，执行某些操作（包括调用第三方Web服务），并更新记录的状态字段以指示处理已完成（或错误，错误计数）。

此操作听起来非常类似于队列。在这种情况下使用MSMQ而不是SQL表有什么好处和权衡，为什么我要选择其中一个呢？

我们的软件是在表格中添加和更新记录。

这是一项将执行异步处理的新工作（Windows服务）。这需要“永远向上”。

Answer 1

有几个原因，在Fog Creek论坛上讨论过：http://discuss.fogcreek.com/joelonsoftware5/default.asp?cmd=show&ixPost=173704&ixReplies=5

主要的好处是，当计算机之间存在间歇性连接时（使用本地计算机上的存储和转发机制），仍然可以使用MSMQ。就应用程序而言，它将消息传递给MSMQ，即使MSMQ稍后可能会传递消息。

只有在可以连接到数据库时，才能将记录插入表中。

当需要工作流方法时，表格方法更好，并且流程将经历各个阶段，并且这些阶段需要在数据库中持久存在。

Answer 2

如果创建预订记录的比率很低，我会让第二个流程定期检查表格中的新预订。

除非您已经在使用MSMQ，否则只需提供一个额外的平台组件即可支持。

如果数据库负载很重，或者您在两个进程读取和写入预订表的同一区域时遇到大量锁争用，那么请考虑引入MSMQ。

Answer 3

我也赞同le dorfier中previous discussion的答案：

  

我先用过表，然后重构   当（和。）成为一个完整的消息队列   if）有原因 - 这是微不足道的   如果你的设计合理。

谢谢，伙计们，所有答案。最有帮助的。

Answer 4

使用MSMQ，您还可以通过将队列的位置更改为另一台计算机而非数据库服务器，将工作轻松卸载到另一台服务器。

顺便说一句，从SQL Server 2005开始，DB中有内置队列。它叫做SQL服务器Service Broker。 请参阅：http://msdn.microsoft.com/en-us/library/ms345108.aspx

Answer 5

另见previous discussion。

Answer 6

如果您拥有MSMQ专业知识，那么这是一个不错的选择。如果您了解数据库但不了解MSMQ，请问自己是否想要成为另一项技术的专家;您的申请是否至关重要;当遇到问题时，你宁愿调试它。

Answer 7

我最近一直在调查这个，所以想提一下我的发现。与您的应用程序相比，数据库的位置是决定哪个选项更快的一个重要因素。

我测试了插入100个数据库条目所花费的时间，而不是将完全相同的数据记录到本地MSMQ消息中。然后我拿了几次执行此测试的结果的平均值。

我发现当数据库在本地网络上时，插入行的速度比登录MSMQ快4倍。

当通过合适的互联网连接访问数据库时，在数据库中插入行的速度比登录MSMQ慢6倍。

所以：

本地数据库 - DB更快，否则MSMQ就是。

Answer 8

如果将服务实现为排队的COM +组件并从客户端应用程序进行排队函数调用，则可能更容易进行原始MSMQ调用。最后，异步服务仍在后台使用MSMQ，但您的代码将更清晰，更易于使用。

Answer 9

我可能会自己选择MSMQ或ActiveMQ。我建议（假设您正在考虑MSMQ，您正在使用Windows，使用MS技术）查看WCF，或者如果您使用的MS-SQL 2005+具有调用.net代码的触发器来运行您的处理。

Answer 10

Service Broker是在SQL 2005中引入的，它旨在快速处理消息，因为该过程相对简单（我相信它的根源在于触发器）。如果您担心可伸缩性，那么在SQL 2008中，他们已经发布了一个独立的处理可执行文件，用于将处理与SQL Server分开（在标准Service Broker中，所有内容都由SQL Server实例控制）。

我肯定会考虑使用Service Broker而不是MSMQ，但这取决于您的SQL开发/ DBA资源及其知识。

Answer 11

除了Mitch的回答，还有其他一些场景： 1.你的每个消息都有自己的截止日期来触发动作，这也可以通过MQ完成，但在这种情况下我更喜欢将它存储到db中，因为它更可控;  2.订阅者需要过滤消息然后处理它的一部分，这也可以通过LINQ来完成，取决于过滤器的复杂程度，db方法更好，因为我可以使用linq来轻松地进行复杂的查询; 3.对于部署，我需要完全自动化的部署过程，以便DB对我来说是更好的选择。我不是手动配置的忠实粉丝。