在已有 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

我支持 Hugh - 我们已成功将 MSMQ（和 IBM MQ 系列）与 BizTalk 一起用于异步事务流量（主要是金融事务，其中对可跟踪、可靠、ACID 类型的消息传递的需求超过了对事务的任何需求延迟）。

我们发现 MSMQ 的好处是：

• 事务传递 - 消息可以由目标系统提取并在 2 阶段 UOW 下插入 SQL。
• Hugh 关于交付与系统可用性脱钩的观点（如果目标系统在不合理的时间段内停机，您仍然有死信队列）
• 负载平衡/节流 - 目标系统可以通过以更均匀的速度从队列中拉出消息来防止过度热心的消息传递。
• 审计 - 使用 MSMQ 上的日志记录允许额外的跟踪层。
• 另请注意，有一个用于 MSMQ 的 WCF 适配器 - 不需要自定义侦听器。

我们一般不会直接从 BizTalk 调用 SQL：

• 读取这相当于轮询数据库，希望有消息准备好发送（这可能会产生与调用频率相关的问题，即冗余、诱导延迟和 SQL 负载以及争用 - 例如轮询同时应用程序正在将数据添加到表中。我们希望每个应用程序决定何时向 BizTalk/ESB 提交消息。
• 对于写入操作，除非将数据卸载到暂存区以供目标应用程序处理，否则可能会导致大部分“业务”处理转移到 BizTalk（即验证、应用业务规则等） - 恕我直言，这太好了- 为 BizTalk 提供粒度。正如您所发现的，很难控制消息传递到 SQL 中的速率（例如，除非您开始使用 Singleton Orhcestrations 等），这又会导致锁定/争用问题。

Answer 2

听起来您应该弄清楚为什么插入需要这么长时间，然后改正它。对于运行 SQL Server 的体面机器而言，每天 10,000 个没什么。

编辑：

添加任何类型的异步处理都是一种将罐头踢下路的形式。假设您的插入需要一分钟（我意识到他们可能不需要，但为了争论）。如果您使插入异步，您仍然每天只能处理 1440 次插入，直到您开始落后。您最终总是需要加快插入速度。

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

Answer 3

我认为，如果您只是想使数据库调用脱机，那么您可以使用 BizTalk 来实现（例如，通过创建“脱机”主机 - 从而创建新的主机队列）。

msmq 真正擅长的地方在于 BizTalk 的入站端。系统可以调用 BizTalk，而不关心 BizTalk 本身的可用性。在 BizTalk 再次可用之前，这些消息将一直存在。