当已经拥有SQL Server和BizTalk时，如何使用MSMQ

Question

简单问题：在已经拥有多个BizTalk和SQL Server节点的现有消息框架中添加MSMQ有什么好处吗？

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

- Sam

Answer 1

听起来你需要找出为什么插入操作如此缓慢，并解决这个问题。对于运行 SQL Server 的良好服务器来说，每天处理 10,000 条记录并不算什么。

编辑：

添加任何形式的异步处理都是在拖延问题。假设你的插入操作需要一分钟（我知道实际上可能不需要那么长时间，但为了论证）。如果你使插入操作变成异步的，你仍然只能每天处理 1440 条记录，否则就会落后。你总是需要加速插入操作。

现在，我认为在使用 MSMQ 或 SSSB 中没有任何强制性的优势。可以说，使用 MSMQ 需要手动编写监听守护进程来执行插入操作，而使用 SSSB，你可以在数据库中自动完成。另一方面，使用 MSMQ，你可以将消息存储转移到另一台服务器上，从而可能减轻 SQL Server 承受的部分压力。

- Chris Shain

---

这并没有回答我的问题，是吗？ - Sam

据我所知，你的问题是“你认为怎么样？”。我理解为你想问的是[MSMQ]“是否是我们技术栈中不必要的添加”。我的回答暗示着“很可能是”，原因是你不应该需要那么长时间来完成一个简单的插入操作。 - Chris Shain

明白了，但请注意，数据库并不只是用于插入这些记录，它还被其他进程大量使用，并且插入的账单信息带有图像。而且，无论您如何调整数据库，在负载增加时问题可能会重新出现，所以为什么不立即尝试修复呢？异步处理是解决问题的方法，我只是想知道为什么选择 MSMQ 而不是其他两种解决方案。 - Sam

Answer 2

我认为，如果你只想将数据库调用离线，那么你可以通过BizTalk来实现这一点（例如，通过创建“离线”主机 - 从而创建一个新的主机队列）。

在BizTalk的入站方面，MSMQ真正擅长。系统调用BizTalk时并不关心BizTalk本身的可用性。消息将一直保留，直到BizTalk再次可用。

- tom redfern

---

是的，这就是为什么我要求一个好的理由来避免那样做并使用MSMQ的原因。 - Sam

因此，您可以说使用现有的工具集以更低的成本实现相同的结果。 - tom redfern

我的意思是，尽管我很喜欢 MSMQ 这项技术，但我无法给你一个好的理由来使用它。 - tom redfern

Answer 3

我和Hugh一样，我们已经成功地将MSMQ（和IBM MQ Series）与BizTalk一起用于异步、事务性流量（主要是金融交易，其中对可追溯、可靠、ACID类型的消息传递的需求超过了对事务延迟的任何需求）。

我们发现MSMQ的好处有：

- 事务性交付 - 目标系统可以将消息从队列中取出并在2阶段UOW下插入到SQL中。 - Hugh指出交付与系统可用性分离的优点（如果目标系统停机时间不合理，您仍然可以使用Dead Letter Queue） - 负载平衡/节流 - 目标系统可以通过以更均匀的速度从队列中取出消息来保护免受过度热情的消息传递的影响。 - 审计 - 使用MSMQ上的日志记录允许附加跟踪层。 - 还要注意，有一个适用于MSMQ的WCF适配器 - 不需要自定义侦听器。

我们通常避免直接从BizTalk调用SQL：

- 对于读取来说，这等同于轮询数据库，希望有准备好发送的消息（这可能会引起与频率相关的问题，例如冗余、感应延迟、SQL负载和争用 - 例如在应用程序向表添加数据时进行轮询。我们宁愿让每个应用程序决定何时将消息提交给BizTalk / ESB。 - 对于写操作，除非数据被卸载到分段区域以供目标应用程序处理，否则会导致大部分“业务”处理移动到BizTalk（即验证、应用业务规则等） - 在我看来，这对于BizTalk来说太细粒度了。正如您发现的那样，很难控制将消息传递到SQL的速率（例如，除非您开始使用Singleton Orhcestrations等），这再次会导致锁定/争用问题。

- StuartLC