sql-server - 在已有 SQL Server 和 BizTalk 时使用 MSMQ

Question

简单的问题:是否有充分的理由将 MSMQ 添加到已有多个 BizTalk 和 SQL Server 节点的现有消息传递框架？

这是背景:我们有一个消息传递框架来处理账单，目前负载很低(每天最多 10,000 个)，但它正在增加。我们使用 BizTalk 和 SQL Server 进行所有处理，并且在(同步)插入其中一个数据库(不是 BizTalk 消息框)时，我们开始注意到一些超时。我们的一位高级程序员建议我们使用 MSMQ 来(异步地)保存导致超时的数据，稍后再处理；他设计的解决方案有效并且即将部署，但我仍然想知道这是否是正确的决定，考虑到我们可以使用 BizTalk 本身或 SQL Server Service Broker (SSSB)。关于这三种技术有很多讨论，但它们通常是关于必须选择其中一种而不是其他技术，我还没有看到任何人已经拥有 BizTalk 和 SSSB 并决定将 MSMQ 添加到组合中。在我们的案例中，我认为这是对我们技术堆栈的不必要的补充，但这可能是我自己的偏见(也是无知)，因为我更了解 SSSB 并且从未对 MSMQ 做过任何大事。你怎么看？

Answer 1

听起来您应该弄清楚为什么您的插入要花这么长时间，然后改正它。 10,000/天对于运行 SQL Server 的像样的机器来说不算什么。

编辑:

添加任何类型的异步处理都是一种把 jar 头踢到路上的形式。假设您的插入需要一分钟(我知道它们可能不需要，但为了争论起见)。如果你让你的插入异步，你仍然每天只能处理 1440 个插入，直到你开始落后。您最终总是需要加快插入速度。

话虽如此，我认为在这种情况下使用 MSMQ 而不是 SSSB(或反之亦然)没有任何令人信服的好处。可以争论的是，对于 MSMQ，您需要手动编写一个监听器守护程序来执行您的插入操作，而对于 SSSB，您可以在数据库中自动拥有它。另一方面，使用 MSMQ，您可以将消息的存储卸载到另一台服务器，可能会卸载 SQL Server 的一些直接压力。